Hacker News Reader

Comment by psanford | Hacker News Reader

No, the keys themselves are fine, and are not going to be "disallowed". Its the SHA-1 part of the signature algorithm that is the problem. Fortunately you can use SHA-2 with your existing "ssh-rsa" keys, as the release notes clearly say:

> The better alternatives include:

> The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them.

View on HN

Honest question: is there any reason for using RSA for new keys these days, if you are not working with extremely legacy systems? My ed25519 works fine with at least CentOS 7, and thankfully that's the oldest system I have to touch.

Maybe only if you want to store the key on a separate physical device, and it only supports RSA?

AWS for some reason only supports RSA keys...

Those are needed for example to push code to their managed git (CodeCommit) and if you want a key added when you launch an EC2 machine and to fetch the Windows password.

Is there a reason for AWS being stuck with RSA? It's not like they lack money or engineering talent.

If you are generating a new keypair, you should default to ed25519. There are still a number of openpgp/smartcard devices that only support RSA keys.

Edit: Another reason one might still use RSA keys: ed25519 isn't a FIPS-140 approved algorithm (yet).

To be fair, “because it is FIPS-140 approved” is also a reason some people give for avoiding an algorithm.

The physical auth devices survive a lot and will last for years / decades. Quite a few of them supported only RSA keys, so don't expect it to go away any time soon.

My almost 10yo yubi still works just fine.

Why not? RSA is perfectly secure and more compatible. Short public key is nice, but does not matter much in reality as you'll copy&paste it anyway.

RSA 1024, which is supported, is not what anybody would call "perfectly secure".

Breaking a 1024-bit RSA key for SSH is a lot of effort for a very minimal reward.

The benefit if you do this is now you can impersonate the key's owner for new connections. So if it's a host key you can pretend to be that host if you're able to get on path between a victim and the real host, if it's a user key you can log in as that user with public key authentication.

But that's an active attack and an expensive key break.

Breaking 1024-bit RSA for HTTPS servers was a much juicier target because you can passively snoop RSA kex in TLS 1.2 and older. But that's not a thing in SSH, it's active attacks only.

RSA 1024 is still almost perfectly secure in practice. Something like the NSA might be able to break it only after the expenditure of years of work and zillions of dollars.

But beside the point as we are talking about RSA 2048 here which is in fact "perfectly secure" and the public key is not the part subject to downgrade attacks.

Azure only supported RSA keys last time I checked.

There's zero reason to ever use RSA for SSH keys, certainly.

Reply on news.ycombinator.com