SSH Keys vs Passwords: How to Secure SSH Access to Your Server

Every server with SSH open to the internet is tried by automated bots within minutes of going online. They guess common usernames and passwords around the clock. A strong password slows them down; an SSH key stops them completely.

This guide explains why keys are safer, then walks through switching a server to key-only login without locking yourself out.

Why SSH keys beat passwords

With password login, you send a secret to the server every time you connect. With key login, the secret never leaves your device:

• Nothing to guess. An Ed25519 private key is 256 bits of randomness. No bot will ever brute-force it.
• Nothing to steal from the server. The server stores only your public key. Copying it gives an attacker nothing.
• Nothing to phish or reuse. People reuse passwords across sites. Keys are generated per device and are useless anywhere else.
• Easy to revoke. Lost a phone? Delete that one public key from the server, and every other device keeps working.

Passwords still have one advantage: you can type them anywhere. That is also exactly why they are risky.

Step 1: Create an Ed25519 key

Ed25519 is the modern default: short keys, fast, and secure. On a computer with OpenSSH:

ssh-keygen -t ed25519 -C "phone-2026"

This creates two files: ~/.ssh/id_ed25519 (private, never share it) and ~/.ssh/id_ed25519.pub (public, safe to copy). The -C comment helps you recognise the key later.

On a phone, use your SSH app’s key generator, or import a key you created on a computer. The private key should be stored in the phone’s secure keychain. In Hectix, keys and passwords are kept only in the iOS Keychain or Android Keystore and are never uploaded.

Step 2: Add the public key to the server

The server reads allowed keys from ~/.ssh/authorized_keys in the home folder of the user you log in as. From a computer, the easiest way is:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

To do it by hand, log in with your password and append the public key:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA... phone-2026" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

The permissions matter. OpenSSH ignores authorized_keys if the folder or file can be written by other users.

Step 3: Test the key before changing anything

Open a new connection using the key, and keep your current session open:

ssh -i ~/.ssh/id_ed25519 deploy@203.0.113.10

If it logs you in without asking for the account password, the key works. If not, check the permissions above and the server’s auth log (journalctl -u ssh or /var/log/auth.log).

Step 4: Turn off password login

Now tell the SSH server to stop accepting passwords. On current Ubuntu and Debian, put your settings in a drop-in file so package updates don’t overwrite them:

sudo nano /etc/ssh/sshd_config.d/10-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Check the configuration, then reload SSH. Reloading keeps existing sessions open:

sudo sshd -t && sudo systemctl reload ssh

On some distributions the service is called sshd instead of ssh. Finally, open one more new session to confirm you can still get in with the key, and that a password is refused:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10   # should be denied

Step 5: Add a few more layers

Key-only login removes the biggest risk. These steps make the server quieter and safer still:

• Firewall. Allow only the ports you need. With UFW: sudo ufw allow OpenSSH, then sudo ufw enable.
• Fail2ban. Bans addresses that keep failing to log in, which cuts log noise.
• Updates. Turn on unattended security updates (unattended-upgrades on Debian and Ubuntu).
• Check host keys. The first time you connect, compare the server’s fingerprint with the one your provider shows. After that, your client warns you if it ever changes.

If you do get locked out

Don’t panic. Most VPS providers offer a web-based console that works without SSH. Log in there, fix authorized_keys or the config file, and reload SSH. This is also why you should test every change in a second session before closing the first.

Summary

Passwords are the weakest part of most servers. Switching to keys takes ten minutes: create an Ed25519 key per device, add the public key to authorized_keys, test it, and turn off password and root login. For day-to-day work after that, see how to manage a Linux server from your phone.

Questions