termalWhen you run ssh-keygen, it asks nothing about the algorithm and quietly picks one for you — and that default has changed over the years. If you’re generating a key today and want the short answer: use Ed25519. The longer answer, and the cases where it’s not that simple, are below.
The one-line recommendation
ssh-keygen -t ed25519 -C "you@device-2026"That’s it. Ed25519 keys are small, fast, and as strong as a 3072-bit RSA key while being a fraction of the size. Unless you have a specific reason not to (one real case below), this is the key to make.
The four you’ll meet
Ed25519 — the modern default. An elliptic-curve signature scheme (Curve25519) designed by Daniel J. Bernstein and collaborators. Fixed size (~68-character public key), fast to generate and verify, and immune to the RNG and parameter footguns that plagued older ECDSA. Supported by OpenSSH since 6.5 (2014), so every current server and service — GitHub, GitLab, your VPS — accepts it. This is the right default in 2026.
RSA — the compatibility fallback. The old workhorse. Still perfectly secure at 3072 or 4096 bits (ssh-keygen -t rsa -b 4096). Its one advantage is reach: some ancient appliance, a legacy jump host, or an enterprise system stuck on an old OpenSSH may not know Ed25519. If you hit no matching host key type, an RSA key is your escape hatch. The catch: bigger keys, slower, and anything under 2048 bits is unsafe — regenerate old 1024-bit keys now.
ECDSA — skip it. Elliptic-curve like Ed25519, but it depends on a per-signature random value that, if the random number generator is weak, leaks your private key (this is how a certain game console’s signing key was recovered in 2010). Ed25519 was specifically designed to remove that failure mode. ECDSA isn’t broken if implemented perfectly, but there’s no reason to choose it over Ed25519 today.
DSA — never. Capped at 1024 bits, disabled by default in modern OpenSSH, being removed entirely. If you find a id_dsa in your ~/.ssh, retire it.
Quick decision
| Your situation | Use |
|---|---|
| Making a key today, normal servers | Ed25519 |
| Must reach an old/legacy system that rejects Ed25519 | RSA 4096 |
| You have an existing ECDSA or 1024-bit key | Regenerate as Ed25519 |
| Anything DSA | Delete it |
Things worth doing while you’re here
Always set a passphrase. A private key with no passphrase is a plaintext password to your servers — anyone who copies the file is you. Add one at generation; unlock it once per session with an agent (AddKeysToAgent yes in your ssh_config).
Name your keys by device, not by “id”. ~/.ssh/id_ed25519 on five machines is five keys you can’t tell apart. laptop_ed25519, work-desktop_ed25519 makes revocation a one-line edit to authorized_keys instead of a guessing game.
Rotate on a schedule, and when a device is lost. A key is a credential; treat it like one. When a laptop dies or is stolen, the fix is removing its public key from every server’s authorized_keys — which is far easier when keys are named per device and you have a list of your servers.
Where a client helps
Generating one key is easy. The friction shows up at scale: which key is on which server, which passphrase goes with which file, and un-trusting a lost device across a fleet. Termalin generates Ed25519 and RSA keys, shows each key’s fingerprint, and unlocks them once through a built-in agent so passphrases aren’t retyped all day — and because it keeps the list of your hosts and keys together (synced across machines, end-to-end encrypted), rotating a compromised key is a visible, finite task rather than an archaeology dig through five ~/.ssh folders.
The algorithm choice, though, stays simple: Ed25519 unless something old forces your hand.
Termalin is a free, cross-platform SSH client that generates and manages your keys with a one-unlock agent — download it, or read the security model.