SSH key authentication replaces passwords with cryptographic key pairs, making brute-force attacks against the SSH port mathematically infeasible — a properly generated Ed25519 or RSA-4096 key cannot be guessed by iterating passwords. Every WordPress server that accepts remote SSH connections should disable password authentication as the first hardening step after key-based login is confirmed working, because password logins remain the primary vector for automated SSH credential attacks. The setup process has three distinct phases: generating a key pair on the client machine, copying the public key to the server’s ~/.ssh/authorized_keys, and then disabling PasswordAuthentication in sshd_config only after verifying that key login succeeds. Skipping the verification step before disabling passwords is the most common mistake — it can lock you out of the server permanently if the key was not copied correctly. Ed25519 keys are preferred over RSA because they are shorter (68 characters versus hundreds), faster to generate and verify, and resistant to side-channel attacks. For servers shared by multiple administrators, each admin’s public key should be added as a separate line in authorized_keys rather than sharing a single key pair — this allows individual revocation without disrupting others. AllowUsers in sshd_config restricts SSH access to an explicit list of usernames, preventing the root account from being targeted even if password authentication were somehow re-enabled. Moving SSH from port 22 to a non-standard port reduces automated scanner noise in the authentication log but is security through obscurity — it supplements but does not replace key authentication and fail2ban. The fail2ban hardening post covers the intrusion prevention layer that protects SSH even before key-only mode is enabled. The PHP-FPM post explains further Linux server configuration that complements SSH hardening to build a fully secured WordPress hosting environment. Back up the sshd_config file before editing it and keep a second terminal session open while reloading SSH so you have a live session to recover from a misconfiguration without being permanently locked out.
Problem: WordPress servers accepting SSH connections with password authentication enabled are continuously targeted by automated brute-force bots that cycle through common credentials — a single weak password on any system user grants full server access.
Solution: Generate an Ed25519 key pair on the client, copy the public key to ~/.ssh/authorized_keys on the server, verify key login succeeds, then set PasswordAuthentication no and PermitRootLogin no in /etc/ssh/sshd_config and reload SSH.
# --- On your LOCAL machine ---
# Generate an Ed25519 key pair (preferred) or RSA-4096
ssh-keygen -t ed25519 -C "deploy@helloadmin.com" -f ~/.ssh/helloadmin_ed25519
# Copy the public key to the server (replaces manual editing)
ssh-copy-id -i ~/.ssh/helloadmin_ed25519.pub deploy@203.0.113.42
# Test key-based login BEFORE changing sshd_config
ssh -i ~/.ssh/helloadmin_ed25519 deploy@203.0.113.42 "echo 'key login OK'"
# --- On the SERVER (only after confirming key login works) ---
# Back up current config
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
# Edit sshd_config — change or add these directives
sudo sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#*PubkeyAuthentication.*/PubkeyAuthentication yes/' /etc/ssh/sshd_config
# Append AllowUsers if not present
grep -q '^AllowUsers' /etc/ssh/sshd_config || echo 'AllowUsers deploy' | sudo tee -a /etc/ssh/sshd_config
# Validate config syntax, then reload (not restart — keeps existing sessions alive)
sudo sshd -t && sudo systemctl reload ssh
# Verify: password auth should now be refused
ssh -o PasswordAuthentication=yes deploy@203.0.113.42 2>&1 | grep -i 'denied\|refused'NOTE: Run sudo sshd -t to validate the configuration file syntax before reloading — a typo in sshd_config causes the reload to fail silently on some distributions, leaving the old config active, while on others it prevents the SSH daemon from restarting after the next reboot, which would lock you out permanently.