How to Set Up SSH Key Authentication and Disable Password Login on Linux

Password-based SSH login is the single most attacked door on any internet-facing Linux server. Automated bots try thousands of common passwords every day. Switching to SSH key authentication — and then turning password login off entirely — removes that attack surface almost completely. This guide takes you through it step by step, with a strong emphasis on not locking yourself out.

How key authentication works

An SSH key pair has two halves: a private key that stays on your computer and must never be shared, and a public key that you copy to the server. When you connect, the two are matched cryptographically. Because the private key never travels over the network, there is no password for a bot to guess.

Step 1: Generate a key pair

On your local machine (not the server), create a modern Ed25519 key:

ssh-keygen -t ed25519 -C "your-email@example.com"

Press Enter to accept the default location (~/.ssh/id_ed25519). When prompted for a passphrase, set one — it encrypts the private key on disk, so a stolen laptop doesn't hand over server access. This creates two files: id_ed25519 (private, keep secret) and id_ed25519.pub (public, safe to share).

Step 2: Copy the public key to the server

The easiest way is ssh-copy-id, which appends your public key to the right file on the server:

ssh-copy-id user@your-server-ip

It will ask for your password this one last time. If ssh-copy-id isn't available, do it manually:

cat ~/.ssh/id_ed25519.pub | ssh user@your-server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Correct permissions matter: SSH refuses keys if ~/.ssh or authorized_keys are too open. The 700 and 600 above are what it expects.

This step is not optional. Open a new terminal and log in:

ssh user@your-server-ip

If you set a passphrase, you'll be asked for it locally (that's the key being unlocked, not a server password). You should land on the server without it asking for your account password. If that works, you're ready to disable passwords. If it doesn't, fix it now — do not proceed.

Step 4: Disable password authentication

On the server, edit the SSH daemon config:

sudo nano /etc/ssh/sshd_config

Find and set these directives (remove any leading # to uncomment them):

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

On many modern systems a file under /etc/ssh/sshd_config.d/ can override the main config, so check there too — a PasswordAuthentication yes in a drop-in file will quietly undo your change.

Step 5: Apply the change safely

Validate the config and reload the service:

sudo sshd -t
sudo systemctl restart ssh

(On some distributions the service is named sshd instead of ssh.) The golden rule: keep your current SSH session open and test a brand-new connection in another terminal before closing it. If the new login still works, you're done. If something is wrong, you still have the original session to fix it.

Don't lock yourself out

Always confirm key login works before disabling passwords.
Keep one session open while testing a second one.
If your provider offers a web console or recovery shell, know where it is — it's your way back in if SSH breaks.
Back up your private key somewhere safe; if you lose it and passwords are off, you lose access.

Common problems

Still asked for a password: the public key didn't land in ~/.ssh/authorized_keys, or permissions are wrong. Re-check Step 2. "Permission denied (publickey)": after disabling passwords, this means the key isn't being accepted — use your provider's console to re-enable PasswordAuthentication temporarily and retrace the steps. Wrong key offered: point SSH at the right key with ssh -i ~/.ssh/id_ed25519 user@server.

Once this is in place, your server only accepts logins from machines holding your private key — a dramatic security upgrade for a few minutes of work.