SSH Keys and Disabling Password Authentication: How to Secure a WordPress Server

Why an SSH Key Is Better Than a Password

When logging in with a password, the server checks the entered character combination. An attacker can automatically send thousands of attempts using dictionaries, reused passwords, or credentials from data breaches. A strong password reduces the risk but does not eliminate the password-guessing mechanism itself.

An SSH key consists of private and public parts. The private key is stored on your computer, while the public key is stored in the user’s profile on the server. The server never receives the private key; instead, it verifies a cryptographic proof during the connection. For additional protection, the private key should always be secured with a passphrase.

This does not mean that an SSH key can be stored without proper controls. If the private key is stolen, an attacker may be able to connect to the server. File permissions, a passphrase, backup procedures, and the timely removal of former employees’ keys are therefore essential.

• Each administrator should have an individual key.
• Do not send private keys through messengers, email, or a ticketing system.
• Do not use one key for all employees: otherwise, it is impossible to revoke access for only one person.
• Ed25519 is generally the preferred modern key type for servers, provided it is supported by both the client and the server.

Creating a Separate User and SSH Key

Routine administration should not be performed as root. Create a regular user account, grant it sudo privileges only when necessary, and first verify that it can actually perform the required tasks.

Run the commands below on your local computer to create the key, and then on the server while logged in as an existing administrator. Replace the username with your own.

• On Linux or macOS, you can create a key with the ssh-keygen command.
• On Windows, equivalent commands are available through OpenSSH in PowerShell; you can also use a compatible SSH client.
• Set a passphrase during key creation. It protects the private key if the file falls into someone else’s hands.

ssh-keygen -t ed25519 -C "admin@example.com"

# On the server as root or another administrator
adduser deploy
usermod -aG sudo deploy

# Transfer the public key to the user
ssh-copy-id deploy@SERVER_IP

If ssh-copy-id Is Unavailable

You can add the public key manually to the ~/.ssh/authorized_keys file of the deploy user. It is important to create the directory with the correct permissions and not to paste the private part of the key.

• Add the line from the .pub file to authorized_keys, not the contents of the private key.
• The ~/.ssh directory is usually assigned permissions of 700, and authorized_keys 600.
• The deploy user should own the files.

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

Test the Connection Before Disabling Passwords

The most dangerous mistake is changing the SSH configuration in the only open session without testing the new login method. If the configuration contains a syntax error or the key has incorrect permissions, the current session may remain the only available access channel.

Open a second terminal window or a separate session and connect as the new user using the key. Do not close the first connection until you have verified login, sudo, and access to the required files.

• Test the login from the same computer or VPN that you will use to administer the server in the future.
• Make sure the SSH client is using the correct key: ssh -i ~/.ssh/key_name deploy@SERVER_IP.
• Run sudo -v or another safe sudo command and verify that the permissions are configured correctly.
• If the connection does not work, view the client’s detailed log with the -v option and check the SSH logs on the server.

ssh -i ~/.ssh/id_ed25519 deploy@SERVER_IP
sudo -v

# Check the sshd configuration before restarting
sudo sshd -t

Why You Should Not Close the Old Session Immediately

The current session does not always terminate after an error in sshd_config. This can create a false sense of security: after you log out, subsequent login attempts may no longer work. Keep the old connection open until all checks are complete, and ensure that you have access to your hosting provider’s console management or another recovery channel.

• Do not edit the configuration without creating a backup.
• Apply changes only after checking the syntax.
• For critical servers, schedule the work during a maintenance window.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
sudo sshd -t

How to Disable Root and Password Authentication

The main SSH settings are usually located in /etc/ssh/sshd_config, but a particular system may also load snippets from /etc/ssh/sshd_config.d/. Check the effective settings and make sure that a later configuration snippet does not override your parameters.

After verifying login with the separate user, add or change the following directives. PasswordAuthentication no disables the password-based login method through SSH.

• PermitRootLogin no — prohibits direct SSH login as root.
• PasswordAuthentication no — disables password login.
• PermitEmptyPasswords no — prevents login for accounts with an empty password.
• AllowUsers deploy — restricts SSH access to the specified user.

PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
AllowUsers deploy

Be Careful with KbdInteractiveAuthentication

Some systems or multifactor authentication setups use keyboard-interactive authentication instead of traditional password authentication. Do not mechanically disable KbdInteractiveAuthentication if MFA or another required login mechanism relies on it. First determine which method your configuration uses.

• If MFA is not used and you want to completely remove interactive password login, you can disable the setting after testing.
• Run sshd -t after making changes.
• Review the effective configuration if the system has many included snippets.

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication|allowusers'

Applying Changes and Restricting Access with a Firewall

After editing the configuration, check its syntax and reload the SSH service. The service may be called ssh or sshd, depending on the distribution. Use reload where available: this applies the configuration without unnecessarily terminating active sessions.

An additional layer of protection is to restrict SSH access with a firewall. The best option is to allow the port only from fixed office, VPN, or administrative network IP addresses. Changing the default port can reduce noise in the logs, but it does not replace keys, a firewall, or disabling passwords.

• Before enabling the firewall, allow SSH from your current IP address or VPN.
• Do not restrict access by IP alone if your provider’s address changes frequently and there is no backup channel.
• Check the rules from a second connection rather than after ending the current session.
• Fail2ban can reduce repeated attempts, but it is not a replacement for key authentication and a firewall.

sudo sshd -t
sudo systemctl reload ssh
# On some systems, the service has a different name:
# sudo systemctl reload sshd

# UFW example: replace the address with your own or your VPN address
sudo ufw allow from ADMIN_IP to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

Common SSH Configuration Mistakes

Problems most often arise not from the key algorithm itself, but from file permissions, the wrong user, or firewall restrictions. Troubleshoot the issue step by step instead of making many changes at once.

• The public key was added to /root/.ssh/authorized_keys even though the connection is made as deploy.
• The .ssh directory or authorized_keys is owned by root or is writable by other users.
• The configuration contains an error, so the SSH service cannot be reloaded.
• AllowUsers does not include the administrative account or contains the wrong name.
• The firewall allows SSH from an IP address different from the one you are actually using.
• All employees’ keys were copied into one account without labels or access controls.
• The only private key is stored on an unencrypted or shared computer.

namei -l /home/deploy/.ssh/authorized_keys
sudo journalctl -u ssh --no-pager -n 50
ssh -v deploy@SERVER_IP

What to Do When an Administrator Leaves

A former employee’s access must be revoked on the server, not merely removed from the corporate chat. Identify the specific line in authorized_keys belonging to that user, delete it, and review login logs. If there is any suspicion that the private key was copied, treat it as compromised and replace it.

• Use comments at the end of the key line, such as a name, device, or date.
• Regularly inventory authorized_keys files.
• For team environments, consider centralized access management and short-lived credentials.
• Do not remove the last working key until you have tested another one.

What Else Matters for a WordPress and Elementor Server

SSH protection does not replace updates for WordPress, themes, plugins, PHP, or the operating system itself. If an attacker gains access to the WordPress dashboard or an vulnerable plugin, SSH keys will not eliminate the consequences of a site compromise.

The administrative SSH account should receive only the permissions required for maintenance. Do not run the web server or PHP processes as root, do not store private keys in the site directory, and do not include keys in backups that are accessible through the web.

Regularly review login logs, create backups outside the server, and test restoration. For a WordPress site, this is no less important than blocking bots: a backup should allow you to restore a working version after a failed update or security incident.

• Enable multifactor protection for the WordPress dashboard and hosting accounts.
• Update Elementor, WordPress, plugins, the theme, and system packages after checking compatibility.
• Limit filesystem permissions and do not use shared administrative accounts.
• Store backups separately from the server and test their restoration.
• Maintain emergency access through the provider’s console or a documented recovery process.