Hacker News Reader

Comment by RL_Quine | Hacker News Reader

From Github data, the overwhelming majority of all SSH keys added by users are ssh-rsa, which will be disallowed soon for older clients. Mind you there still a number of users with ssh-dss which is just comical.

Remember that you can download the SSH public keys of any user on Github and run these statistics yourself.

    https://github.com/linus.keys

Linus for example seems to have two keys, a 1024 bit RSA and a 2048 bit RSA.

View on HN

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.

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?

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.

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

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.

Azure only supported RSA keys last time I checked.

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".

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.

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.

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.

> From Github data, the overwhelming majority of all SSH keys added by users are ssh-rsa, which will be disallowed soon. Mind you there still a number of users with ssh-dss which is just comical.

It seems that this is partially the fault of all the big git hosts "guides" for new beginners.

GitHub's guide shows how to create an RSA key. [3] There's no information about why you would choose RSA or anything else. You're expected to make an RSA key.

Atlassian's guide shows how to create an RSA key. [0] They at least spell out there are other options, but DSA is the first of them, and they don't say anything about the types.

The GitBook isn't as specific in the commands it says to use, but shows RSA as the output. [1]

GitLab actually doesn't recommend RSA, and spells out the choice a bit more than most, but that seems like a recent change. [2] Props to them.

[0] https://confluence.atlassian.com/bitbucketserver/creating-ss...

[1] https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-...

[2] https://docs.gitlab.com/ee/ssh/

[3] https://docs.github.com/en/free-pro-team@latest/github/authe...

FTA:

>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.

It's unclear to me whether I'm using SHA1 or SHA2. Running ` ssh -oHostKeyAlgorithms=-ssh-rsa ` against one of my servers works, and I'm sure to have created my key before 2016 when OpenSSH 7.2 was released.

If you run with -vv during auth there's some debug text to do with cryptography selection. In the case of github the response is:

    debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss>

Which suggests you'll be using rsa-sha2-256 with your client version, or absolutely nothing in the future if you're using one of the older releases such as on MacOS.

It doesn't matter when you created your key. This is protocol stuff. If you're using non-ancient OpenSSH, and the server is using non-ancient OpenSSH, and you haven't done anything silly like disable the sha2 signature algorithms, then you're already using them since they're preferred by default.

Unless you're using certificates, your rsa keys don't specify any hashing algo at all. The negotiating between the client and server decide the signature algo.

Reply on news.ycombinator.com