21–30 of 61 posts
Notable in this release is support for generating and using keys backed by FIDO/U2F tokens (and, with supported tokens, keys fully resident in FIDO/U2F tokens that you can transport between computers).
Notably from the changelog: It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.
Just for fun, most users on Github have RSA keys exclusively. Did you know that your SSH keys are public on Github? https://github.com/taylorotwell.keys https://github.com/alexcrichton.keys https://github.com/andrew.keys https://github.com/egoist.keys https://github.com/fabpot.keys Some of the most popular users even have DSS keys.
Rare ecdsa-sha2-nistp256 guy here. I'd welcome Brainpool, but support mostly boils down to NIST compromised curves on the majority of applications. sadface
> Did you know that your SSH keys are public on Github?
Wait, what? Github makes public keys public? Outrageous!
Earlier quoted context omitted.
As a RSA-user myself, because I learnt about ssh through the github setup guides: Will ssh-keygen generate a secure key if I don’t pass it any parameters?
I haven't built the new version, but I assume it defaults to ed25519 now. You can otherwise make one with ssh-keygen -t ed25519.
Earlier quoted context omitted.
You are conflating RSA (the algorithm) with "ssh-rsa" (the option of the SSH suite indicating authentication with RSA in combination with SHA-1). They deprecate the latter. Other options also based on RSA such as "rsa-sha2-256/512" are fine and will remain supported. In other words, the security problem is not with RSA per se. Having said that, I have not checked whether the people you list have RSA keys bound to SHA…
The keys themselves are not bound to sha1 or sha256. The hash is just used for the ephemeral signatures during authentication (or certificates as mentioned in the release notes). "ssh-rsa" signature scheme at runtime (sha1) will be deprecated, but rsa keys themselves are fine (edit typo name)
The option in ssh-keygen for a signature algorithm is for signing keys in an SSH CA. This is not something Github supports.
Notable in this release is support for generating and using keys backed by FIDO/U2F tokens (and, with supported tokens, keys fully resident in FIDO/U2F tokens that you can transport between computers).
I'm happy to see this, however I'd be far more excited if I thought there was a chance of it landing in the upcoming Ubuntu 20.04 release - else I'll likely be waiting impatiently until 22.04 for server-side support.
Earlier quoted context omitted.
Just for fun, most users on Github have RSA keys exclusively. Did you know that your SSH keys are public on Github? https://github.com/taylorotwell.keys https://github.com/alexcrichton.keys https://github.com/andrew.keys https://github.com/egoist.keys https://github.com/fabpot.keys Some of the most popular users even have DSS keys.
> Just for fun, most users on Github have RSA keys exclusively. Rare ecdsa-sha2-nistp256 guy here. I'd welcome Brainpool, but support mostly boils down to NIST compromised curves on the majority of applications. sadface > Did you know that your SSH keys are public on Github? Wait, what? Github makes public keys public? Outrageous!
Notably from the changelog: It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.
https://developercommunity.visualstudio.com/idea/365980/supp...
Earlier quoted context omitted.
The keys themselves are not bound to sha1 or sha256. The hash is just used for the ephemeral signatures during authentication (or certificates as mentioned in the release notes). "ssh-rsa" signature scheme at runtime (sha1) will be deprecated, but rsa keys themselves are fine (edit typo name)
Right. Most SSH keys are just keys, not hashes. The hash used for key exchange during authentication is something that is enforced by the server (and client) and not a property of the key. The option in ssh-keygen for a signature algorithm is for signing keys in an SSH CA. This is not something Github supports.
actually, they do now[1], but only for enterprise accounts. Which is a shame - this is useful for "normal people" too.
1: https://help.github.com/en/github/setting-up-and-managing-or...