6 ms·

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

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.

psanford 6y ago
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.
- throwaway8941 6y ago
  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?
  - psanford 6y ago
    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).
    - klodolph 6y ago
      To be fair, “because it is FIPS-140 approved” is also a reason some people give for avoiding an algorithm.
  - RL_Quine 6y ago
    There's zero reason to ever use RSA for SSH keys, certainly.
  - vladvasiliu 6y ago
    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.
    - ChuckNorris89 6y ago
      Is there a reason for AWS being stuck with RSA? It's not like they lack money or engineering talent.
  - dochtman 6y ago
    Azure only supported RSA keys last time I checked.
  - vbezhenar 6y ago
    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.
    - RL_Quine 6y ago
      RSA 1024, which is supported, is not what anybody would call "perfectly secure".
      - upofadown 6y ago
        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.
      - tialaramex 6y ago
        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.
  - viraptor 6y ago
    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.
nemothekid 6y ago
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.
- RL_Quine 6y ago
  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.
- _-___________-_ 6y ago
  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.
- georgyo 6y ago
  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.
shakna 6y ago
> 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-ssh-keys-776639788.html https://confluence.atlassian.com/bitbucketserver/creating-ss... [1] https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-... [2] https://docs.gitlab.com/ee/ssh/ https://docs.gitlab.com/ee/ssh/ [3] https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent https://docs.github.com/en/free-pro-team@latest/github/authe...

psanford 6y ago

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.

throwaway8941 6y ago
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?
- psanford 6y ago
  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).
  - klodolph 6y ago
    To be fair, “because it is FIPS-140 approved” is also a reason some people give for avoiding an algorithm.
- RL_Quine 6y ago
  There's zero reason to ever use RSA for SSH keys, certainly.
- vladvasiliu 6y ago
  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.
  - ChuckNorris89 6y ago
    Is there a reason for AWS being stuck with RSA? It's not like they lack money or engineering talent.
- dochtman 6y ago
  Azure only supported RSA keys last time I checked.
- vbezhenar 6y ago
  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.
  - RL_Quine 6y ago
    RSA 1024, which is supported, is not what anybody would call "perfectly secure".
    - upofadown 6y ago
      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.
    - tialaramex 6y ago
      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.
- viraptor 6y ago
  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.

nemothekid 6y ago

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.

RL_Quine 6y ago
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.
_-___________-_ 6y ago
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.
georgyo 6y ago
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.

shakna 6y ago

> 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-ssh-keys-776639788.html https://confluence.atlassian.com/bitbucketserver/creating-ss... [1] https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-... [2] https://docs.gitlab.com/ee/ssh/ https://docs.gitlab.com/ee/ssh/ [3] https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent https://docs.github.com/en/free-pro-team@latest/github/authe...