Ed25519 vs RSA for SSH Keys: Which Should You Generate in 2026?

Every time you git push or ssh into a server, a key pair proves who you are without sending a password. Generating one takes a single command — but ssh-keygen offers several algorithms, and old tutorials still recommend rsa -b 4096. Here's how the options compare today.

The options at a glance

Why Ed25519 is the default choice

Ed25519 is a signature scheme over Curve25519, designed by Daniel J. Bernstein and colleagues in 2011 and standardized in RFC 8032. Its advantages are practical, not just theoretical:

• Small keys. A 256-bit Ed25519 key gives roughly the same security as a 3,072-bit RSA key. The whole public key line fits on one terminal row, which makes authorized_keys files readable and copy-paste errors rarer.
• Fast. Generating an Ed25519 key is instant; signing and verifying are much faster than RSA at equivalent strength.
• Deterministic signatures. ECDSA needs a fresh random number for every signature, and a weak or repeated one leaks the private key — this is how the PlayStation 3 signing key was extracted in 2010. Ed25519 derives that value from the message and key, eliminating the whole failure class.
• Fewer ways to get it wrong. No parameter choices, no padding schemes, and constant-time implementations by design, which resist timing side channels.
• Strong private-key protection by default. OpenSSH stores Ed25519 private keys in its own format, encrypted with a passphrase via bcrypt-pbkdf, which is much harder to brute-force than the old PEM format.

Generating an Ed25519 key

ssh-keygen -t ed25519 -C "you@example.com"
# Enter file:  ~/.ssh/id_ed25519   (press Enter for the default)
# Passphrase:  use one — it encrypts the private key on disk

$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA...  you@example.com

$ ssh-keygen -lf ~/.ssh/id_ed25519.pub
256 SHA256:mEMMcnEiCw0jpI+ARdwooLTB8zUghjfYk1rRiSFxkTU you@example.com (ED25519)

The -C comment is just a label to help you recognise the key later. Add -a 100 to raise the number of key-derivation rounds that protect the passphrase (the default is 16) — this makes an offline attack on a stolen key file slower at the cost of a fraction of a second when you unlock it.

Then copy the public key to a server with ssh-copy-id user@host, or paste the contents of id_ed25519.pub into GitHub, GitLab or your cloud provider's SSH key settings. Never share the file without `.pub` — that's your private key.

When you still need RSA

Ed25519 has been in OpenSSH since 2014 (version 6.5), so almost everything supports it. Exceptions you may hit:

• Servers running very old distributions (RHEL/CentOS 6 era) or unpatched appliances.
• Some network gear, embedded devices and legacy SFTP services.
• Environments that mandate FIPS 186-4–era algorithms (newer FIPS 186-5 does approve EdDSA, but adoption lags).

ssh-keygen -t rsa -b 4096 -C "you@example.com"
# OpenSSH's default RSA size is already 3072 bits if you omit -b

Is RSA-4096 "more secure" than Ed25519? On paper it has a slightly higher classical security level (~140 bits vs. ~128), but 128 bits is already far beyond any feasible attack. In practice RSA-4096 just means larger keys and slower handshakes. Against a future quantum computer, both RSA and Ed25519 fall equally — size doesn't save RSA.

The "ssh-rsa" confusion

Since OpenSSH 8.8 (2021), connections fail with errors like no matching host key type found. Their offer: ssh-rsa. This makes many people think RSA keys are banned. They aren't. The name ssh-rsa refers to RSA signatures with SHA-1, which OpenSSH disabled because SHA-1 collisions became practical. The same RSA key works fine with the rsa-sha2-256 and rsa-sha2-512 signature schemes.

So if an old server only speaks ssh-rsa, the right fix is to upgrade the server. As a temporary workaround for one host only, you can re-enable it in ~/.ssh/config with HostKeyAlgorithms +ssh-rsa and PubkeyAcceptedAlgorithms +ssh-rsa — never globally.

Hardware-backed keys: ed25519-sk

If you own a FIDO2 security key (YubiKey, SoloKey, Google Titan and others), you can generate a key whose private half never leaves the hardware:

ssh-keygen -t ed25519-sk -O resident -C "you@example.com"

Each login then requires a physical touch, so malware on your laptop can't silently use the key. GitHub, GitLab and recent OpenSSH servers (8.2+) support these. Laptops with a secure enclave (Apple Silicon, TPM 2.0) can offer similar protection through SSH agents like Secretive or a TPM-backed agent.

What post-quantum cryptography changes for SSH

SSH uses public-key cryptography in two different places, and quantum computers threaten them differently:

1. Key exchange — negotiating the session key that encrypts your traffic. An attacker could *record* traffic today and decrypt it once a quantum computer exists ("harvest now, decrypt later"). OpenSSH has defended against this since version 9.0 (2022), and since OpenSSH 10.0 (2025) the default key exchange is mlkem768x25519-sha256, a hybrid of the NIST-standard ML-KEM and classic X25519.
2. Authentication — your Ed25519 or RSA key proving identity. A future quantum computer could forge this, but only in real time — it can't retroactively impersonate you in a session that already happened. There's no standardized post-quantum SSH signature in OpenSSH yet.

So keep your Ed25519 key, keep OpenSSH up to date, and you already have the part of post-quantum protection that matters most today. You can check your client's preference with ssh -G example.com | grep kexalgorithms. More in our post-quantum cryptography guide.

Good SSH key hygiene

• Protect private keys with a passphrase and use ssh-agent (or your OS keychain) so you type it once per session.
• One key per device, not one key copied everywhere — so a lost laptop means revoking one key.
• Audit `authorized_keys` on servers periodically; remove keys you don't recognise. The SSH fingerprint tool shows the SHA256 fingerprint of a public key so you can match it against ssh-keygen -lf output.
• Verify host fingerprints the first time you connect to a server instead of blindly typing *yes*.
• Consider SSH certificates for teams: a CA signs short-lived user keys, so there are no long-lived authorized_keys entries to manage.