ssh
Ed25519 vs RSA: Which SSH Key Should You Actually Generate?
A clear, opinionated comparison of Ed25519 and RSA SSH keys — speed, security, key size, and compatibility — plus a simple decision rule and the exact command to generate each.
When you run ssh-keygen, you’re quietly choosing a cryptosystem. For years RSA was the default and nobody thought twice. Today the answer is simpler than the debate makes it sound: generate Ed25519 unless something specifically forces you back to RSA. Here’s why, and how to know when that “something” applies.
The short answer
| Ed25519 | RSA | |
|---|---|---|
| Security (modern) | Excellent | Excellent at 3072/4096-bit |
| Key size | Tiny (68-char public key) | Large (a 4096-bit key is a wall of text) |
| Key generation | Instant | Noticeably slower at 4096-bit |
| Signing/verify speed | Faster | Slower |
| Resistance to weak-RNG footguns | High (deterministic, fixed curve) | Lower (bad params/short keys are possible) |
| Compatibility | OpenSSH 6.5+ (2014) | Universal, including ancient systems |
| Good default? | Yes | Only when Ed25519 isn’t accepted |
Ed25519 is an elliptic-curve signature scheme (Curve25519). It gives you security comparable to a ~3000-bit RSA key while the key itself is small enough to fit on one line, and it’s less prone to the parameter mistakes that have historically weakened RSA deployments.
Why Ed25519 is the default now
Three practical wins:
- Small keys, same strength. A 256-bit Ed25519 key matches roughly RSA-3072 for security but is a fraction of the size. Your
authorized_keysandknown_hostsstay readable. - Speed. Key generation is instant and signatures are fast — you feel it on constrained hardware and CI runners.
- Fewer ways to get it wrong. RSA’s security depends on key length and a good random prime generation; short RSA keys (1024-bit) are broken, and weak RNGs have produced factorable keys in the wild. Ed25519 fixes the curve and is deterministic, removing whole categories of footgun.
When you actually still want RSA
RSA isn’t obsolete — it’s the compatibility fallback:
- Legacy servers or appliances running OpenSSH older than 6.5 (pre-2014), or non-OpenSSH SSH implementations that never added Ed25519.
- Corporate/enterprise systems — some hardware, jump hosts, or managed Git servers still only accept RSA.
- A policy or FIPS requirement that mandates RSA.
If you hit “key type not supported,” that’s your signal. Use RSA at 4096 bits — never 1024, and 2048 only if a system won’t take 4096.
Generating each
Ed25519, the one-liner you’ll use most:
ssh-keygen -t ed25519 -C "[email protected]"RSA, when compatibility forces it:
ssh-keygen -t rsa -b 4096 -C "[email protected]"The -C comment just labels the key (an email is conventional); it isn’t secret.
No terminal handy? Generate in your browser
If you’re on a locked-down machine without a shell — or you just prefer clicking a button — the SSH Key Generator creates either an Ed25519 or an RSA pair entirely in your browser with the Web Crypto API. Pick Ed25519 (the default) and you get a standard OpenSSH-format keypair — the same id_ed25519 / id_ed25519.pub files ssh-keygen would write, ready to drop into ~/.ssh and add to authorized_keys. Choose RSA (2048/4096-bit) for the compatibility case instead. Everything runs client-side — no key material is ever transmitted anywhere. The same rule extends past SSH: TLS certificate requests can be built browser-side too, and a CSR generator should never see your private key.
The decision rule
Generate Ed25519. If a server rejects it, generate RSA 4096. Never use 1024-bit anything, and never reuse one key everywhere — one key per machine or per purpose makes revocation painless.
One last thing once the key exists: SSH refuses to use a private key that other users can read, so the file needs chmod 600 and ~/.ssh needs 700 — see chmod 755 vs 644 if those numbers aren’t second nature yet.
Want more on the crypto underneath your auth stack? See how bcrypt works for password hashing and how TOTP 2FA works for the codes in your authenticator app.