5 ms·

> 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

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

RL_Quine 7y ago
It's not intuitive because there's really no need for it.
- dspillett 7y ago
  No harm in it either though. 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.
  - RL_Quine 7y ago
    What you described is quite literally a feature in Ubuntu Server. Type in a github username during the installer to import from github.com/%s.keys to /root/.ssh/authorized_keys.
    - tialaramex 7y ago
      My instinct is that's actually safer than a "set your password and open SSH to the world" step.
    - 3fe9a03ccd14ca5 7y ago
      A cronjob on every one of my IoT crap devices, which sometimes stay stuffed in a shoebox without internet for years: @reboot root ssh-import-id gh:my-username That way when I want to tinker with one, it will pull down my newest GitHub once it reboots and I’ll be able to login. The GitHub key is always up to date.
    - dspillett 7y ago
      > Type in a github 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...
  - boring_twenties 7y ago
    The harm is that if you use the same key elsewhere, it can be linked to your github identity.
    - dspillett 7y ago
      If you are needing to keep your identity hidden/ambiguous, then you need to be careful with your keys. Don't publish a public key if you don't want it to be public! 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.
      - boring_twenties 7y ago
        I think it's fine as long as you _know_ github is going to make it public. The only problem is that it's not at all obvious, as can be seen in this very thread.
jwilk 7y ago
Why not ssh-ed25519?
- numlock86 7y ago
  > Why not ssh-ed25519? > [...] 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.

RL_Quine 7y ago

It's not intuitive because there's really no need for it.

dspillett 7y ago
No harm in it either though. 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.
- RL_Quine 7y ago
  What you described is quite literally a feature in Ubuntu Server. Type in a github username during the installer to import from github.com/%s.keys to /root/.ssh/authorized_keys.
  - tialaramex 7y ago
    My instinct is that's actually safer than a "set your password and open SSH to the world" step.
  - 3fe9a03ccd14ca5 7y ago
    A cronjob on every one of my IoT crap devices, which sometimes stay stuffed in a shoebox without internet for years: @reboot root ssh-import-id gh:my-username That way when I want to tinker with one, it will pull down my newest GitHub once it reboots and I’ll be able to login. The GitHub key is always up to date.
  - dspillett 7y ago
    > Type in a github 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...
- boring_twenties 7y ago
  The harm is that if you use the same key elsewhere, it can be linked to your github identity.
  - dspillett 7y ago
    If you are needing to keep your identity hidden/ambiguous, then you need to be careful with your keys. Don't publish a public key if you don't want it to be public! 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.
    - boring_twenties 7y ago
      I think it's fine as long as you _know_ github is going to make it public. The only problem is that it's not at all obvious, as can be seen in this very thread.

jwilk 7y ago

Why not ssh-ed25519?

numlock86 7y ago
> Why not ssh-ed25519? > [...] 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.