Ed25519 vs RSA for SSH keys
Use Ed25519. The interesting part is the handful of cases where you can't.
Generate an Ed25519 key pair
The answer, and then the nuance
Use Ed25519. It has been the right default since OpenSSH 6.5 shipped it in 2014, and GitHub, GitLab and every current server accept it. The public key is one short line instead of a paragraph, signing and verification are fast, and — the part that actually matters — there is nothing to configure. No key size to pick, no padding scheme to get wrong, no exponent. RSA's history of vulnerabilities is mostly a history of parameter choices; Ed25519 does not offer you the chance to make them.
Isn't RSA-4096 stronger than a 256-bit key?
No — the numbers are not comparable, and this is the most common misreading in the whole topic. RSA's security comes from factoring difficulty and Ed25519's from the elliptic-curve discrete log problem, and they scale completely differently. Ed25519 offers roughly 128 bits of security, which is about what RSA-3072 gives you. RSA-4096 is somewhat above that and costs you noticeably slower handshakes for a margin nobody can use: 128 bits of security is already beyond any conceivable classical attack. Bigger is not stronger here, it is just slower. Both, incidentally, fall to a sufficiently large quantum computer — RSA-4096 buys you nothing there either.
ssh-rsa the signature algorithm is not RSA the key
OpenSSH 8.8 disabled the ssh-rsa signature scheme by default in 2021, and a lot of people read that as "RSA is deprecated". It isn't. What was disabled is RSA with SHA-1, because SHA-1 is broken. The same RSA key works fine with rsa-sha2-256 and rsa-sha2-512. If an old server rejects your key after an OpenSSH upgrade, the key is not the problem — the server is too old to offer a SHA-2 signature, and the fix is on that side.
When you genuinely need RSA
Legacy targets, and that is about it: appliances, embedded systems, hardware security modules, some enterprise Git servers and old jump hosts that predate 2014 and will never be upgraded. If you hit one, generate ssh-keygen -t rsa -b 4096 and keep it scoped to that host — there is no reason to make your everyday identity RSA because one router insists on it. Your ~/.ssh/config can point a specific IdentityFile at a specific Host, and you should let it.
What about ECDSA?
Skip it. It sits between the two with no advantage over Ed25519, it depends on NIST curves whose provenance some people distrust, and — concretely — it fails catastrophically if the implementation's nonce generation is weak, which is precisely the failure that leaked Sony's PS3 signing key. Ed25519 generates its nonce deterministically from the message and the key, so that entire class of bug cannot happen.
Is RSA-4096 stronger than Ed25519?
Not usefully. The numbers are not comparable — RSA rests on factoring and Ed25519 on the elliptic-curve discrete log problem, and they scale differently. Ed25519 gives roughly 128 bits of security, comparable to RSA-3072. RSA-4096 is somewhat above that and costs you slower handshakes for a margin no attacker can cross either way.
Is RSA deprecated for SSH?
No — this is a common misreading. OpenSSH 8.8 disabled the ssh-rsa signature scheme, which is RSA with SHA-1, because SHA-1 is broken. The same RSA key works fine with rsa-sha2-256 and rsa-sha2-512. If a server rejects your key after an OpenSSH upgrade, the server is too old to offer a SHA-2 signature.
When do I still need RSA?
Legacy targets, essentially: appliances, embedded systems, HSMs, and enterprise servers predating 2014 that will never be upgraded. Generate ssh-keygen -t rsa -b 4096 and scope it to that host with an IdentityFile entry in ~/.ssh/config. There is no reason to make your everyday identity RSA because one device insists.
What about ECDSA?
Skip it. It has no advantage over Ed25519, it depends on NIST curves some people distrust, and it fails catastrophically if nonce generation is weak — the exact bug that leaked Sony's PS3 signing key. Ed25519 derives its nonce deterministically from the message and key, so that class of failure cannot occur.
Nothing leaves your browser
- Don't take our word for it — turn off your wifi. Every generator on this site keeps working with the network disconnected. That's the whole proof, and it takes five seconds.
- Every value comes from
crypto.getRandomValues()— the CSPRNG built into your browser, neverMath.random(). - Generated secrets are never transmitted, logged or stored: no server-side generation, no cookies, no localStorage.
- Verify it yourself in the network tab: after loading, the page only talks to our self-hosted, cookie-less analytics — which counts page views and which generator type gets copied, never any value.
- Strict Content-Security-Policy; no third-party script origins.