If your server accepts SSH logins with just a username and password, it is being probed constantly — check /var/log/auth.log and you'll see failed login attempts from unfamiliar IPs within hours of setup. Key-based authentication removes that entire attack surface. The one thing that trips people up is disabling passwords before confirming the key actually works — do that and you can lock yourself out permanently. This order avoids it.
01Generate a key pair on your local machine
Not on the server — on the computer you connect from.
ssh-keygen -t ed25519 -C "your-email@example.com"
Press Enter to accept the default file location. Set a passphrase when prompted — this protects the key itself if your laptop is ever stolen, separate from server security.
02Copy the public key to your server
The easiest method, if you can still log in with a password right now:
ssh-copy-id username@your-server-ip
If ssh-copy-id isn't available (common on Windows), do it manually:
cat ~/.ssh/id_ed25519.pub | ssh username@your-server-ip \
"mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
03Confirm key login works — do not skip this
Open a new terminal window without closing your current session, and try connecting:
ssh username@your-server-ip
You should log in without a password prompt (or only your key's passphrase). If this fails, stop here and fix it — keep your original session open until it's resolved.
04Only now, disable password authentication
Edit the SSH daemon config:
sudo nano /etc/ssh/sshd_config
Find and set these values:
PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes
Restart the SSH service:
sudo systemctl restart sshd
05Verify again in a fresh session
Before closing your original terminal, open one more new window and confirm you can still connect with your key. Only close the original session once a completely fresh login succeeds.
| Mistake | Consequence |
|---|---|
| Disabling passwords before testing the key | Total lockout if the key doesn't work — often requires console/rescue access from your host |
| Copying the private key to the server instead of the public key | Defeats the purpose; the private key must never leave your machine |
Wrong permissions on ~/.ssh | SSH silently refuses to use the key; run chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys |