Ed25519 vs RSA vs ECDSA: which SSH key should you use?

Short answer: Ed25519. It is fast, small, hard to misuse and supported by everything you are likely to connect to. RSA 4096 is for old systems that refuse it.

updated 9 October 2026

ssh-keygen -t ed25519 -C "[email protected]"
ssh-keygen -t rsa -b 4096 -C "[email protected]"

What the key type decides

The -t option of ssh-keygen chooses the signature algorithm your key uses to prove who you are. That is all it controls. The encryption of the session itself is negotiated separately by client and server, with its own key exchange and cipher, whatever your key type.

Three things follow from the choice:

• Security margin: how much work it would take to forge your signatures.
• Size and speed: how long the public key is, how fast it signs, and how fast it is to generate.
• Compatibility: whether the server, appliance or library on the other end understands it.

Servers have keys of their own too, the host keys in /etc/ssh. The same comparison applies to them, but you rarely choose those by hand; sshd generates one of each type at install time.

At a glance

Security levels are the usual estimates (NIST SP 800-57 for RSA): the approximate number of operations, as a power of two, needed to break the key with the best known classical attack. Anything at 112 bits or more is out of reach today.

Ed25519: the modern default

EdDSA over Curve25519, designed in 2011 to be fast and hard to get wrong. OpenSSH added it in 6.5 and recommends it for new keys; since OpenSSH 9.5, ssh-keygen creates an Ed25519 key when you give no -t at all.

• Deterministic signatures. The per-signature value that ECDSA must draw at random is derived from the key and the message instead. A bad random number generator at signing time cannot leak the key.
• Built for constant time. The curve arithmetic has no secret-dependent branches, which shuts out the timing side channels that have hit RSA and ECDSA implementations.
• No parameters to choose. There is one curve and one key size, so there is no -b to get wrong.
• Short keys. The whole public key fits on one line of a terminal, which makes it easy to paste, compare and audit in authorized_keys.

Since FIPS 186-5 (2023), EdDSA is also approved for US federal systems.

RSA: universal, but heavy

Everything supports RSA. Its keys must be big: 2048 bits is the minimum, 3072 the ssh-keygen default, 4096 adds margin at the cost of speed. Recent OpenSSH releases refuse RSA keys shorter than 1024 bits outright, and many services require 2048.

Choose RSA, at 3072 or 4096 bits, when you must connect to:

• servers running OpenSSH older than 6.5, such as long-unpatched enterprise distributions;
• network appliances, routers, older NAS boxes and embedded devices whose SSH stack lacks Ed25519;
• software or hardware tokens, cloud consoles or compliance tools that only accept RSA.

Going beyond 4096 bits buys little: signing gets much slower and some software rejects larger keys, while the attack that would break RSA 4096 in practice, a large quantum computer, would break any RSA size.

ssh-rsa vs rsa-sha2-256 and rsa-sha2-512

One common confusion: OpenSSH 8.8 disabled the ssh-rsa signature algorithm, which uses SHA-1. RSA keys are not deprecated. They keep working by signing with rsa-sha2-256 or rsa-sha2-512, which every server since OpenSSH 7.2 (2016) understands.

The public key line still starts with ssh-rsa, because that is the name of the key format. Only the way signatures are hashed changed. Problems appear only when one side is old:

• An old server that only knows SHA-1 signatures rejects your RSA key with Permission denied (publickey), or offers only an SHA-1 host key, which current clients reject with no matching host key type found. Their offer: ssh-rsa.
• An old client, such as an outdated library in a deployment tool, cannot log in to a current server with an RSA key, and the server logs that the key type is not in PubkeyAcceptedAlgorithms.

The right fix is to update the old side or use an Ed25519 key. As a stopgap, allow SHA-1 for that one host only, in your client's ~/.ssh/config:

Host legacy-box
  HostName 192.0.2.10
  HostKeyAlgorithms +ssh-rsa
  PubkeyAcceptedAlgorithms +ssh-rsa

ECDSA: fine, but rarely the best choice

ECDSA uses the NIST curves P-256, P-384 or P-521. Its weak point is the random nonce each signature needs: a reused or predictable nonce leaks the private key, as with the PlayStation 3 signing key in 2010. Ed25519 removes that risk by design.

Pick ECDSA when a policy requires NIST curves, or when your smart card or TPM supports only those. Choose the size with -b 256, 384 or 521; 256 is the default and usually enough.

DSA: do not use

DSA keys are limited to 1024 bits and share ECDSA's nonce weakness. OpenSSH disabled them by default in version 7.0 and removed DSA support entirely in version 10.0. Replace any id_dsa you still have.

Speed in numbers

A single measurement with openssl speed on one core of a current x86-64 desktop (OpenSSL 3.5). Absolute numbers depend on the machine; the ratios are what matter.

Your client signs once per login, so even RSA 4096's 3 milliseconds go unnoticed on a laptop. The difference shows on slow hardware, on hardware tokens, in automation that opens thousands of connections, and when generating keys in a browser, where RSA 4096 can take several seconds because the search for primes is random.

Compatibility: what supports Ed25519

If you are not sure about a device, try the Ed25519 key first. A server that does not support it simply refuses it, and ssh moves on to the next key or the password prompt.

FIPS and compliance

EdDSA became a FIPS-approved signature algorithm with FIPS 186-5 in 2023. What counts in practice is whether the certified crypto module on your systems includes it, and older validated modules do not. Some distributions running in FIPS mode therefore refuse Ed25519 keys. In that case use ECDSA P-256 or P-384, or RSA 3072 or larger, and check your organisation's policy rather than the standard alone.

Hardware keys: ed25519-sk and ecdsa-sk

With a FIDO2 security key, ssh-keygen creates a key whose secret half never leaves the device. The file in ~/.ssh is only a handle; without the physical token it is useless, and each login needs a touch.

ssh-keygen -t ed25519-sk -C "yubikey"
ssh-keygen -t ecdsa-sk -C "older-token"

Prefer ed25519-sk; some older tokens support only ecdsa-sk. Both need OpenSSH 8.2 or later on the client and the server. Options such as resident keys are covered in the ssh-keygen reference.

What about quantum computers?

None of these key types would survive a large quantum computer, Ed25519 no more than RSA. But:

• Your traffic is already protected. OpenSSH 9.0 made the hybrid sntrup761x25519-sha512 key exchange the default, and OpenSSH 10.0 switched the default to the hybrid mlkem768x25519-sha256. Sessions recorded today cannot be decrypted later, whatever your authentication key type. OpenSSH 10.1 and later warn when a connection falls back to a key exchange without a post-quantum part.
• Authentication is not retroactive. A key only has to resist attack while it is in use. User and host keys in OpenSSH are still classical; when post-quantum signature keys arrive, you will rotate to them, just as you would rotate any key.

Choosing RSA 4096 over Ed25519 "for quantum safety" therefore buys nothing. To see which key exchange a connection used, run ssh -v host 2>&1 | grep "kex: algorithm".

Check your key type and switch

List the keys you have and their types:

$ ssh-keygen -lf ~/.ssh/id_rsa.pub
3072 SHA256:0XHmc2iPdHK4onDhCP/Ld0QjtAQ0yVtcZpgmN0XbE7s you@laptop (RSA)

The first number is the size in bits and the type is in brackets. Moving to Ed25519 takes a few minutes:

1. Generate the new key with ssh-keygen -t ed25519. It gets its own file name, so the RSA key stays.
2. Add the new public key to GitHub and the other git hosts (how) and to each server's authorized_keys (how).
3. Log in everywhere with the new key, for example with ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes host.
4. Remove the old public key from those places, then archive or delete the RSA key.

Recommendation

• New personal or work key: Ed25519, protected by a passphrase.
• Something old refuses it: an additional RSA 4096 key for that system only.
• Highest assurance: ed25519-sk on a FIDO2 hardware key.
• Existing RSA 2048+ keys: keep using them, rotate when convenient.
• DSA or RSA below 2048 bits: replace now.

Generate either type locally:

ssh-keygen -t ed25519 -C "[email protected]"
ssh-keygen -t rsa -b 4096 -C "[email protected]"

Or in your browser with the sshkeygen.dev generator.