The comparison
| Ed25519 | RSA 3072 | RSA 4096 | |
|---|---|---|---|
| Estimated security | About 128 bits | 128 bits | Between 128 and 192 bits |
| Public key file | 92 bytes | 564 bytes | 736 bytes |
| Private key file, no passphrase | 399 bytes | 2590 bytes | 3369 bytes |
| Size choice | None, always 256 bits | Set with -b | Set with -b |
| Needs on the other side | OpenSSH 6.5 or later | Almost any SSH server | Almost any SSH server |
The file sizes come from keys we generated with the comment you@laptop. The security estimates are from RFC 8032 for ed25519 and NIST SP 800-57 for RSA.
What really matters
- Fewer choices to get wrong. An ed25519 key has one size, so nobody can create a weak one by accident.
ssh-keygenignores-bfor this type: we asked for 4096 and got 256. - Short public keys. One line that fits in a chat message or a config file without being cut.
- Protection of the file. A key with no passphrase on a stolen laptop is exposed whatever its type. This matters far more than the difference between the two algorithms.
To keep each key and its passphrase in one place, see the SSH key manager with an encrypted vault.
Generate each type
ssh-keygen -t ed25519 -C "you@laptop"
ssh-keygen -t rsa -b 4096 -C "you@laptop"Without -b, RSA keys are 3072 bits, the default since OpenSSH 8.0. Since OpenSSH 9.5, ssh-keygen with no -t makes an ed25519 key. See how to generate an ed25519 key for the full steps.
RSA key sizes
- Below 1024 bits:
ssh-keygenrefuses withInvalid RSA key length: minimum is 1024 bits. - 1024 bits: do not use. It can still be generated, but a server with a higher
RequiredRSASizerefuses it. That setting exists since OpenSSH 9.1 and its default is 1024. - 2048 bits: NIST rates this at 112 bits of security. It works, but it is the old minimum, so replace it when you next rotate keys.
- 3072 or 4096 bits: use one of these if you need RSA.
When RSA is still the right choice
- A server runs OpenSSH older than 6.5.
- An old network device, appliance or embedded system lists only RSA keys in its documentation.
- A compliance rule or a system in FIPS mode limits the key types you can use. Check the list from your vendor.
You can keep one key of each type and use RSA only for the hosts that need it:
Host old-server
IdentityFile ~/.ssh/id_rsa
IdentitiesOnly yesConnecting to old systems
An RSA key is not the same thing as the signature made with it. Since OpenSSH 8.8, the client no longer uses the old ssh-rsa signature, which relies on SHA-1, unless you ask for it. The same key file still works with the newer rsa-sha2-256 and rsa-sha2-512 signatures, which OpenSSH supports since 7.2.
A server that knows only the old algorithm gives you this error:
Unable to negotiate with 203.0.113.10 port 22: no matching host key type found. Their offer: ssh-rsaFor that one host, and only if you cannot upgrade it, turn the old algorithm back on:
ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa user@old-serverThis weakens the connection, so keep it out of Host *. A new RSA key does not help here, because the problem is the signature and not the key. See also no mutual signature supported and no matching key exchange.
DSA and ECDSA
DSA is gone: OpenSSH 10.0 removed it, and ssh-keygen -t dsa now answers unknown key type dsa. Replace any DSA key you still have. ECDSA works and is widely supported, but it gives you no advantage over ed25519 unless a system requires it.
Check the keys you have
for f in ~/.ssh/*.pub; do ssh-keygen -lf "$f"; doneThe first number is the size and the last word is the type, for example 3072 SHA256:... you@laptop (RSA).
Questions
Is RSA 4096 stronger than ed25519?
On paper it has a somewhat higher security estimate, but both are far beyond what can be attacked today, so it is not a reason to choose it. Theft of the private key file is the practical risk, and a passphrase helps there with either type.
Can I convert an RSA key to ed25519?
No. They are different kinds of keys. Generate a new ed25519 key, add its public key to your servers, test the login, then remove the old public key.
Does a quantum computer change the choice?
No, not between these two: a large enough quantum computer would break both. OpenSSH 10.6 enables a hybrid post-quantum key type, made with ssh-keygen -t mldsa44-ed25519, but both sides need 10.6 or later. For the key exchange, see the post-quantum warning guide.
Sources
- ssh-keygen(1), OpenBSD manual
- OpenSSH 8.8 release notes
- OpenSSH release notes
- RFC 8032, EdDSA
- NIST SP 800-57 Part 1 Rev. 5