Ed25519 or RSA in 2026?

“RSA is disabled” is not what happened. OpenSSH turned off one signature algorithm whose name only looks like it means RSA — and the difference decides whether your key needs replacing.

Written and maintained by OnePasswordManager Ltd. Last checked against current documentation on 21 August 2026.

Why did my RSA key suddenly stop working?

Almost certainly because the server is old, not because your key is. OpenSSH 8.8, released on 26 September 2021, disabled one specific signature algorithm by default. The release note gives the reason in its own words: "This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K". The algorithm switched off is named ssh-rsa, and the confusion begins with that name: it sounds like it means "RSA", but it means "RSA signed with SHA-1". The same RSA key can also be used with rsa-sha2-256 and rsa-sha2-512, which are not affected and are what any maintained server has been using for years.

A key is not an algorithm

An RSA key file on your disk does not have a hash algorithm baked into it. The hash is chosen at connection time, by negotiation between your client and the server. So when a connection fails with a message about no matching host key type or no acceptable signature algorithm, the thing that is too old is the software at one end of the connection, not the bytes in ~/.ssh/id_rsa. A server that can only do ssh-rsa is running an OpenSSH from before 2017 or an embedded SSH implementation that was never updated. That is worth knowing for its own sake: it tells you something about the machine you are logging into, and it is usually a bigger problem than the connection you are trying to make.

Which key type should I generate in 2026?

The practical reason to prefer Ed25519 over RSA has less to do with strength than with predictability. An Ed25519 key is always the same size, so there is no decision to make and no way to accidentally generate something too small. The public key is short enough to paste into a single line without wrapping, which quietly removes a whole class of copy-paste failures when adding it to authorized_keys. And because support arrived in OpenSSH 6.5 in 2014, effectively every server you will meet in 2026 accepts it. The exceptions are the same ancient or embedded implementations that would have given you trouble anyway.

Generating one

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

The comment after -C is free text stored in the public key. Use something that identifies the machine rather than the person — you will be reading it later in a server's authorized_keys file, trying to work out which laptop a key belongs to so you can decide whether to remove it. "laptop-2026-work" answers that question. An email address, which is the conventional default, does not.

What if I genuinely have to reach an old server?

You can re-enable the old algorithm for that one host, and the OpenSSH project tells you how while making its opinion clear. The release note says it may be necessary to "selectively re-enable RSA/SHA1 to allow connection and/or user authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms options", and then adds: "We recommend enabling RSA/SHA1 only as a stopgap measure until legacy implementations can be upgraded or reconfigured with another key type (such as ECDSA or Ed25519)." Scope it to the host that needs it and nothing else. A global Host * block that re-enables SHA-1 signatures turns a single legacy exception into a permanent downgrade for every server you connect to.

Host legacy-box.internal
  HostkeyAlgorithms +ssh-rsa
  PubkeyAcceptedAlgorithms +ssh-rsa

The leading + matters. It adds the algorithm to the default list rather than replacing the list with just that one entry, which is what happens if you leave the plus out and is almost never what you want.

How do I find out what I already have?

List the fingerprints of every key in your .ssh directory and you get the type of each one in the output, in brackets at the end of the line. This is a better starting point than looking at filenames, because filenames lie: an id_rsa that someone regenerated years ago may not be RSA, and a key with no conventional name at all may be the one your server actually accepts. The same command run against a public key file tells you the fingerprint you can compare with what a server or a hosting provider has on record for you.

for k in ~/.ssh/*.pub; do ssh-keygen -l -f "$k"; done

If a key you rely on turns out to be RSA and the servers you use are current, there is no emergency. Rotating to Ed25519 is a good idea and not an urgent one. If a key turns out to be DSA, that is different: OpenSSH 10.0 removed the code, so it will stop working the moment either end is upgraded, and you should replace it now rather than discover the problem during an outage.