RBRunbook
Networking

How to Set Up SSH Key Authentication and Disable Password Login

Passwords on a public-facing server get brute-forced eventually. Key-based login closes that door in about ten minutes.

DifficultyIntermediate
Time15–20 min
PlatformLinux VPS
CategoryNetworking

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.

MistakeConsequence
Disabling passwords before testing the keyTotal 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 keyDefeats the purpose; the private key must never leave your machine
Wrong permissions on ~/.sshSSH silently refuses to use the key; run chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
Extra step worth taking Most cloud hosts (DigitalOcean, Linode, AWS Lightsail, Hetzner) offer a browser-based console that works even if SSH is broken. Confirm you can access it before you start, as a safety net.
JM
Written by Jordan Malik Senior Editor, Systems & Networking — guide tested on a live Linux VPS setup before publishing
Last verified: July 2026