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.
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_keysis 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.