It's not quite the same in the end from the end user's perspective, no. If you were logging into servers running a recent-ish version of OpenSSH (i.e. newer than 2016), you would continue to be able to log in with your RSA keypairs with no changes, because the client and server would still be able to negotiate a signature algorithm that both support. It just so happens that very old versions of OpenSSH don't support any of the signature algorithms used with RSA keys that new clients prefer to use. In other words:

> or re-configure your OpenSSH client to continue allowing RSA even though the creators of OpenSSH have deprecated it by default

^ this is not correct. RSA is not deprecated by default. A specific signature algorithm used with RSA keys is deprecated. But yes, if your server is running a very old version of OpenSSH, that may be the only signature algorithm it supports.

I'm not sure there are any distro releases running versions of OpenSSH this old that aren't EOL though, so really you should probably update your servers, which would also take care of this. (I suppose if you're running CentOS 7 or RHEL 7 you still get security updates for the next 1.5 years at least, but it's no longer actively supported.)

> Thanks for the clarification, but from the end user's perspective it's all the same in the end?

The vast majority of users will not experience this unless their client is old. I literally dealt with this issue yesterday with one of our lead Developers.

He was using JSch in an older version of dbeaver, couldn't SSH into the new test environments we're validating on Ubuntu 22.04. Turns out to be this exact issue. The solution was to update dbeaver and switch to the new default SSHJ client within it.

Same private key, new client. Problem solved.

I will be using this as leverage to force a company standard change from RSA4096 keys to ed25519. So I am not going to clarify the difference to the Security teams.

RSA keys aren’t deprecated (apart from those with shorter key lengths, e.g. 1024 bits). What’s deprecated is the use of SHA-1, and in consequence the signature algorithms that combine SHA-1 with RSA. Instead you have to use signature algorithms that combine other hash algorithms (like SHA-2) with RSA. RSA itself, and RSA keys, remain unaffected.

Another thing that may get deprecated in the coming years is RSA 1.5 padding, requiring to use PSS padding instead. Again, that doesn’t impact RSA keys, but only the algorithm parameters used with RSA.

In the context of TLS/SSH, it just means that client and server have to negotiate the RSA-based algorithm variant they both support and both deem to be safe, using the existing RSA keys.