How do you set up SSH keys and lock down SSH on a Linux VPS?

Which key type should you create in 2026?

Create an ed25519 key: it is the default of ssh-keygen, short enough to paste anywhere, and accepted by every current server. Three other cases:

• A hardware key. ed25519-sk keeps the private key on a FIDO2 token such as a YubiKey; each login needs a touch. Both ends need OpenSSH 8.2 or newer, which every image in our list ships.
• RSA. Still accepted when it is 3072 bits or longer. OpenSSH 8.8 turned off by default only the old ssh-rsa signature scheme based on SHA-1, not RSA keys themselves.
• DSA. Gone. OpenSSH 10.0 removed it in April 2025, and the Debian 13 release notes say DSA keys no longer work at all.

Use one key per device and name it in the comment. Revoking a lost laptop is then one line to delete, not a key to replace everywhere.

ssh-keygen -t ed25519 -C "alice-laptop-2026"

# or with a FIDO2 hardware key
ssh-keygen -t ed25519-sk -C "alice-yubikey-2026"

# the public half: this is what you paste at checkout
cat ~/.ssh/id_ed25519.pub

# load it once per session so the passphrase is asked only once
ssh-add ~/.ssh/id_ed25519

Where does the public key go?

At checkout for the first one, then in ~/.ssh/authorized_keys on the server for every other device. You log in as root over SSH. Add a public key at checkout and password login stays disabled; skip it and the team sets a temporary root password, shown in your dashboard, that you change with passwd the first time you log in.

The private key never leaves your computer and is never asked for. To add a second device later, ssh-copy-id appends its public key over a login that already works. By hand, the rules are strict: the .ssh directory in mode 700, authorized_keys in mode 600, both owned by the user. sshd ignores a file that others can write.

A Host block in ~/.ssh/config saves typing and makes ssh offer only the right key. That matters once your agent holds many keys: sshd closes the connection after MaxAuthTries failed attempts, 6 by default.

# from the new device, while another key still works on the server
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# ~/.ssh/config
Host web1
    HostName 203.0.113.10
    User alice
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

How do you check you reached the right server?

Compare the fingerprint your client stored with the one the server holds. On the first connection ssh shows the server's host key fingerprint and records it in ~/.ssh/known_hosts. Once logged in, print the server's own fingerprint and compare the two. They must match character for character.

A later warning that the host key changed has one innocent cause on a VPS: a reinstall, which creates new host keys. Reboot, reinstall and delete are requests you send from the dashboard, carried out by a person. A reinstall erases the disk. If you asked for a reinstall, remove the old entry with ssh-keygen -R. If you did not, stop and ask support before you type a password or forward anything.

# on the server
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

# on your computer: what known_hosts recorded
ssh-keygen -lF 203.0.113.10

# after a reinstall you asked for
ssh-keygen -R 203.0.113.10

How does sshd read drop-in files, and why does the name matter?

sshd keeps the first value it reads for most keywords, so the file read first wins. The sshd_config manual says so in one line. Debian and Ubuntu put Include /etc/ssh/sshd_config.d/*.conf at the top of /etc/ssh/sshd_config, and the matching files are read in alphabetical order. Two consequences:

• A drop-in beats the main file, whatever the main file says further down.
• Among drop-ins, 00-hardening.conf beats 50-cloud-init.conf. Cloud images often carry that second file, sometimes with PasswordAuthentication yes. A 99-hardening.conf would lose to it.

Trust sshd -T over your reading of the files: it prints the values the daemon will use. Then test from outside with password login forced; the server must answer Permission denied (publickey).

cat > /etc/ssh/sshd_config.d/00-hardening.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowUsers alice
EOF

sshd -t && systemctl restart ssh      # AlmaLinux, Rocky: systemctl restart sshd
sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin|allowusers)'

# from your computer, in a second terminal: this must fail
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]

What else cuts down what an attacker can try?

• Fewer open ports. A firewall that allows 22 and the ports of your services only. Better still, reach SSH over a private tunnel and close it to the world: WireGuard on a VPS shows how.
• A jump host instead of agent forwarding. ssh -J alice@bastion alice@db1 reaches an inner server without exposing your agent on the middle machine, which ForwardAgent yes does.
• Post-quantum key exchange. OpenSSH 10.0 made mlkem768x25519-sha256 the default key agreement, and since 10.1 the client warns when a connection falls back to one without post-quantum protection. Debian 13 ships OpenSSH 10.0p1. If you see that warning, the old side needs an upgrade; there is nothing to configure.
• fail2ban, if you want shorter logs. With keys only it adds little safety. Debian 12 and 13 log to the systemd journal, so the jail needs backend = systemd.

apt install fail2ban python3-systemd
cat > /etc/fail2ban/jail.d/sshd.local <<'EOF'
[sshd]
enabled = true
backend = systemd
EOF
systemctl restart fail2ban
fail2ban-client status sshd

What happens if you lose your key?

Keep two keys on the server from the first day: your laptop's and a second one kept apart, such as a hardware token or an offline copy. Losing one then costs a line in authorized_keys, not a server. No dashboard action brings back a lost private key: it never left your computer.

Your customer account is a separate key with its own rule. You sign in with an account number alone; adding an email is up to you. Your account number is the only key to the account. With an email on file you can get it back; without one, a lost number cannot be recovered. Store the account number and your SSH keys in different places, so one lost bag does not take both.

Which plan do you need for this?

Any of them: SSH hardening costs no CPU and no RAM. The smallest, Byte (1 vCPU / 2 GB / 40 GB), also makes a good jump host in front of servers you run elsewhere, at $2.25 a month on a 12-month term or $3.21 month to month. Every VPS runs Linux, installed from our Debian, Ubuntu, AlmaLinux or Rocky Linux images; Windows is not sold.