Choose the right SSH key type

The fix

ssh-keygen -t ed25519 -C "you@workstation"

Then install it on the host while you still have a working login:

ssh-copy-id -i ~/.ssh/id_ed25519.pub youruser@host

Why it matters

The key type decides the strength of the only credential you have left once password authentication is off. It also decides whether your key still works after an OpenSSH upgrade — one algorithm has already been removed outright.

The four types, and which to use

Ed25519 — use this. Fast, compact, and with no parameter choices to get wrong. There’s no “how many bits” question to answer badly. Supported by every OpenSSH since 6.5 (2014), so interoperability is rarely a real constraint today.

RSA — only for interoperability. Still fine at 3072 or 4096 bits, and still what some appliances, managed platforms and older embedded systems accept. If you need it:

ssh-keygen -t rsa -b 4096 -C "you@workstation"

Note that RSA key size and the RSA signature algorithm are separate things. OpenSSH 8.8 stopped accepting ssh-rsa (SHA-1) signatures by default; the same RSA key works fine via rsa-sha2-256/rsa-sha2-512. If an old device fails to authenticate after an upgrade, that’s usually this, not the key length.

ECDSA — no reason to pick it. It works, but it offers nothing over Ed25519 and depends on NIST curves that some organisations avoid. Not harmful, just pointless for new keys.

DSA — gone. OpenSSH disabled it by default in 9.8 and removed it entirely in 10.0 (released 2025), completing a deprecation that started in 2015. A DSA key is not weak-but-working on a current host; it simply cannot authenticate. If you find one, replace it.

Hardware-backed keys

If your workstation has a FIDO2 authenticator (a YubiKey, or a platform authenticator), OpenSSH 8.2+ can generate a key whose private half never leaves the hardware:

ssh-keygen -t ed25519-sk -C "you@yubikey"

Authentication then requires the physical device to be present and touched. This is the simplest genuine second factor available for SSH — see Add a second factor.

Verify it worked

Check what type and size a key actually is:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Expect a line starting with 256 and ending in (ED25519).

Then confirm which key the server accepted, rather than which one you think it used:

ssh -v youruser@host 'true' 2>&1 | grep -i 'server accepts key\|Authenticated to'

Before you apply this

Generating a key changes nothing until you install it — and installing it changes nothing until you test it.

Never remove an old key from ~/.ssh/authorized_keys on the server until you have logged in with the new one from a second terminal:

ssh -i ~/.ssh/id_ed25519 youruser@host

If you are rotating keys on a host where you have already disabled password authentication, the old key is your only way back in. Add the new key, verify it, then remove the old one — in that order, never the reverse.

Related

• Require key-only SSH authentication — apply this first.
• Add a second factor to SSH — hardware-backed keys.