Set Up SSH Key Login and Disable Passwords on an Ubuntu Server

Typing a password every time you connect to your Ubuntu home server gets old quickly. Worse, password login is the part of SSH that attackers hammer day and night, trying common passwords against any server they can reach. SSH keys solve both problems at once: logging in becomes a single command with no typing, and the login itself becomes far stronger than any password you would realistically choose.

This guide takes you from a working password login to key-only login, in a safe order. The golden rule runs through every step: never disable password login until you have proved, in a separate session, that your key works. Follow the steps in sequence and you will finish with a server that is easier for you to use and much harder for anyone else to enter.

Quick Answer

Generate a key pair on your own computer with ssh-keygen -t ed25519, copy the public key to the server with ssh-copy-id yourname@server, and test that you can log in with the key in a new terminal window. Only then edit /etc/ssh/sshd_config on the server to set PasswordAuthentication no and PubkeyAuthentication yes, and restart SSH with sudo systemctl restart ssh. Keep your existing session open until the new settings are fully tested.

How SSH Keys Work in Plain Language

An SSH key pair is two matched files. The private key stays on your computer and never leaves it. The public key goes on the server, inside a file called authorized_keys in your home folder. When you connect, the server challenges your computer to prove it holds the private half. Your computer proves it mathematically, without sending the key itself, and the server lets you in.

Because a key is a long random value rather than something a human memorised, it cannot be guessed in any realistic time. That is why key login stays strong even when a server is reachable from the internet, while password login depends entirely on the strength of one typed secret.

Step 1: Generate Your Key Pair

Do this on the computer you will connect from, not on the server.

1. Open a terminal. On Windows, the built-in OpenSSH client works in PowerShell or Windows Terminal; on macOS and Linux, use your normal terminal.
2. Run ssh-keygen -t ed25519 -C "my home server". Ed25519 is the modern recommended key type: fast, small, and secure.
3. Accept the default location, which is ~/.ssh/id_ed25519 on Linux and macOS, or the equivalent under your Windows user profile.
4. Set a passphrase for the key when prompted. This protects the key file if your computer is lost or copied. It is optional, but strongly recommended.
5. Confirm both files exist: the private key id_ed25519 and the public key id_ed25519.pub. Only the file ending in .pub is ever shared.

Step 2: Copy the Public Key to the Server

The easiest method uses a small tool designed for exactly this job.

1. Run ssh-copy-id yourname@192.168.1.50, replacing the username and address with your server details.
2. Enter your normal SSH password one last time for this step. The tool appends your public key to ~/.ssh/authorized_keys on the server and sets safe permissions.
3. If ssh-copy-id is not available on Windows, copy the key manually. Display it with cat ~/.ssh/id_ed25519.pub, log in to the server with your password, and paste the whole single line into the server file using nano ~/.ssh/authorized_keys.
4. On the server, make sure permissions are strict: chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys. SSH ignores key files it considers too open.

The official Ubuntu Server documentation on OpenSSH keys covers the same process with distribution-specific notes, and it is worth bookmarking for server administration tasks.

Step 3: Test Key Login Before Changing Anything

This step is the safety net for the whole guide. Do not skip it.

1. Open a brand new terminal window, leaving your current session untouched.
2. Connect with ssh yourname@192.168.1.50.
3. You should be asked for your key passphrase, if you set one, but not for the server account password. If the server still asks for the account password, the key was not accepted and you must troubleshoot before continuing.
4. Force a key-only test with ssh -o PasswordAuthentication=no yourname@192.168.1.50. If this connects, the key alone is genuinely doing the work.
5. Troubleshoot failures by checking the three usual causes: wrong permissions on .ssh or authorized_keys, the key pasted with line breaks instead of one line, or connecting as a different user than the one whose folder holds the key.

Step 4: Disable Password Login on the Server

With key login proven, harden the server configuration.

1. On the server, back up the configuration: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.
2. Check the drop-in folder too. Run ls /etc/ssh/sshd_config.d/, because on Ubuntu cloud and some installer images a file in that folder can override the main settings. If a file there mentions password authentication, edit that file instead or as well.
3. Open the configuration with sudo nano /etc/ssh/sshd_config and set or add these lines: PubkeyAuthentication yes, PasswordAuthentication no, and KbdInteractiveAuthentication no.
4. Optionally, also set PermitRootLogin no so the root account cannot be reached directly over SSH at all. Use your normal account and sudo instead.
5. Validate the file before restarting: sudo sshd -t. Silence means the configuration is valid. Fix any reported error before going further.
6. Apply the change with sudo systemctl restart ssh.

Setting names and file locations follow the official OpenSSH sshd_config manual page, which lists every option and its exact meaning if you want to explore further hardening later.

Step 5: Verify the Locked-Down Server

Now prove the new rules behave exactly as intended, still keeping your original session open as a fallback.

1. In a new terminal, connect normally with your key. It should work exactly as before.
2. Test that password login is really refused: ssh -o PubkeyAuthentication=no yourname@192.168.1.50. The server should reject the attempt with a permission denied message about publickey authentication.
3. Only after both tests pass should you close the original session you kept open during the change.
4. If you administer the server from more than one computer, repeat the key copy and test from each machine before you need it in a hurry.

For a broader checklist that pairs this change with updates, firewall rules, and user management, see our Ubuntu server security basics guide for home administrators.

Using Your Key Day to Day

A few small habits make key login painless. Add your key to the SSH agent once per session with ssh-add, so you type the passphrase once instead of on every connection. Create a short alias in ~/.ssh/config on your computer with the server address, username, and key file, so connecting becomes as simple as ssh homeserver. Back up your private key securely, for example on an encrypted USB stick stored safely, because losing it after disabling passwords means regaining access through the server console or a recovery mode boot.

Common Mistakes and Useful Tips

• Disabling passwords before testing the key. This is the classic self-lockout. Always prove key login in a fresh session first.
• Closing the only working session too early. Keep one authenticated session open until every test passes after the restart.
• Sharing the private key. Only the .pub file goes on servers. A private key that has been emailed or copied around should be replaced.
• Loose permissions on the server. If authorized_keys is writable by others, SSH silently refuses it. Use 700 for the folder and 600 for the file.
• Forgetting the sshd_config.d overrides. On some Ubuntu images a drop-in file wins over the main configuration. Check both places before concluding the setting is ignored.
• Tip: give each of your computers its own key rather than copying one private key everywhere. If a machine is lost, you remove only its line from authorized_keys.

Conclusion

Key-based SSH login is one of the best upgrades you can give a home server: quicker for you, and dramatically stronger against attack. Generate an Ed25519 key, install the public half on the server, test it thoroughly in a separate session, and only then switch password authentication off in the SSH configuration. Verify both directions, key accepted and password refused, before closing your safety session. Done in that order, the change is safe, reversible, and permanent in the best way.

Frequently Asked Questions

What if I lose my private key after disabling password login?

You will need another route in: a second computer whose key is also authorised, a local console or monitor attached to the server, or the hosting provider console for a virtual server. This is why testing a backup key and keeping a secure key backup matter.

Is a key passphrase the same as the server password?

No. The passphrase unlocks the private key file on your own computer. The server never sees it. The server account password is the separate credential you are disabling for SSH login.

Can I use the same key pair on several servers?

Yes. Your one public key can sit in authorized_keys on many servers. The better practice is one key per client computer, reused across servers, so a lost computer affects only its own key.

Why does the server still ask for a password after I set PasswordAuthentication no?

Usually a drop-in file in /etc/ssh/sshd_config.d/ is overriding the main file, or the SSH service was not restarted. Check both, run sudo sshd -t, and restart the service again.

Should I also change the default SSH port?

It is optional. A different port reduces background noise in logs but adds little real security compared with key-only login. Strong keys and disabled passwords are the changes that actually protect the server.