How to use SSH keys and turn off password login

Bots try to guess SSH passwords all day. With a key and password login turned off, guessing stops working. This takes about ten minutes.

Golden rule: keep your current SSH session open until you have tested a new login in a second window. If something goes wrong, you can still fix it.

These steps are for Ubuntu and Debian servers. You run steps 1 and 2 on your own computer, the rest on the server.

1. Make a key on your computer

Open a terminal (on Windows, PowerShell works) and run:

ssh-keygen -t ed25519

Press Enter to accept the usual file name, and pick a passphrase when asked. The passphrase protects the key if your laptop is stolen. This creates two files: a private key (keep it secret, never copy it to a server) and a public key ending in .pub (safe to share).

2. Copy the public key to the server

ssh-copy-id you@your-server

Use your normal user, not root. You type your password one last time. The command adds your public key to ~/.ssh/authorized_keys on the server.

No ssh-copy-id (for example on Windows)? Copy the text of your .pub file into ~/.ssh/authorized_keys on the server by hand, on a line of its own.

3. Test the key

Open a new terminal window and log in again with ssh you@your-server. If it asks for your key's passphrase (or nothing at all) instead of the server password, the key works. Don't go on until this works.

4. Turn off password login

Newer Ubuntu and Debian versions read extra settings files from /etc/ssh/sshd_config.d/, and the first value SSH finds for a setting wins. Some cloud images ship a file there that turns password login back on. So put your settings in a file whose name sorts first:

sudo nano /etc/ssh/sshd_config.d/00-keys-only.conf

Add these lines and save:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

PermitRootLogin no stops anyone logging in as root directly. If you only have the root user, create a normal user with sudo rights first, and copy your key to that user.

5. Check, then apply

First check the settings for mistakes. No output means no errors:

sudo sshd -t

Then see what SSH will really use:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractive|permitrootlogin'

All three should say no. If one says yes, another file in /etc/ssh/sshd_config.d/ is winning. Then restart SSH:

sudo systemctl restart ssh

Your open session stays connected.

6. Test again from a new window

Log in with your key in a new window: it should work. Then try a password login, which should be refused:

ssh -o PubkeyAuthentication=no you@your-server

You should see Permission denied (publickey). Now you can close the old session.

If you get locked out

Most hosting providers offer a web console (sometimes called VNC, rescue or serial console) that works without SSH. Log in there, remove or fix /etc/ssh/sshd_config.d/00-keys-only.conf and restart SSH.

Good next steps

  • Keep a second key (for example on another computer or a hardware key) in authorized_keys, so losing one laptop doesn't lock you out.
  • Remove keys of people who no longer need access. Each line in authorized_keys is one key.
  • Add a second step, so a stolen key alone isn't enough: a code from an authenticator app.
  • Work through the rest of our security checklist for a new PHP server.

Official sources

ServerNest is being built to let you turn password login on or off from a dashboard, with a check that your key still works. Join early access to try it first.

← Back to the security blog