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.
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-1...
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...
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!
Unless for some reason someone imports one into their authorized_keys (which presumably would require deliberate steps not random numbskullary) in which case there is a (low) risk as they have just given a dev access to an account said dev does not know exists.
Type in a github username during the installer to import from github.com/%s.keys to /root/.ssh/authorized_keys.
@reboot root ssh-import-id gh:my-username
Exactly. That would be the deliberate steps I mentioned as a gate for this causing a problem. If you give it someone else's key you have a problem, though a minor one unless you've been conned into doing so by an adversary who will later scan for accounts that allow their key pair for auth.
Importing your own public key this way is not problematical at all.
Of course you might end up with people publishing their private key along with the private one, by error or because it seems convenient & they don't think things through...
These keys and the ways people often used them are very much not designed with privacy as a priority: they are explicitly for proving who you are so you can be given access to something. Key management with regard to keeping different concerns separated is up to the user.
> [...] but support mostly boils down to NIST compromised curves on the majority of applications.
I am doing a lot of embedded stuff, and usually all that's supported is RSA ... and NIST curves when it comes to ECC. And I like to keep my key count at 1. Ditching RSA for ECC was a huge step already in that regard.