I don't think it's super well known, but it is very handy. Used it in the past to give people SSH access by just asking for GitHub user, and then basically just doing `curl https://github.com/victorb.keys >> ~/.ssh/authorized_keys` without sending keys back/forward.
Keybase (or similar) would ideally be used for this instead, but they chose to go a very weird route for their tool, and are now disappearing completely eventually probably.
There is also a tool ssh-import-id. It could do the similar with the command "ssh-import-id gh:<github username>".
It checks if key is already in authorized_keys, and it's handy if you want to run the command in idempotent manner.
It's available in Ubuntu packages, don't know about other distributions.
Why? I think the best practice is that you should use different keys for different client devices, not that you should use different keys for different services. A separate key per client allows a service to ban individual client devices if they get compromised, there's no practical scenario where a client device would want to ban individual services.
> A separate key per client allows a service to ban individual client devices if they get compromised
This isn't possible with the "oh I synced your public keys from GitHub" pattern. The user might revoke a key later (we all rotate our keys every six months, right?), and remove it from GitHub but it can still be used to access your service.
Maybe this is OK if you sync from GitHub on every access request (or cache for a short period), using it as a poor man's OAuth, but that's not what GP was proposing.
Even if you had different keys to different services, you'd never revoke just one of those keys. If you're revoking a key because your client device was compromised: well, your other service keys on the same device are compromised too. If you're revoking a key because you regularly rotate your keys every 6 months: well, you're revoking all those other keys from all those other services at around the same frequency, separate service keys aren't helping you revoke less.
There's never a practical scenario where you'd just revoke one service-client key-pair while the other service-client key-pairs are totally safe. Imagine your GitHub-specific private key was compromised somehow - a private key that has never left your laptop that also stores private keys for all your other services - do you think it's safe to only revoke your GitHub-specific key?
This is exactly the problem. You need to revoke your key (maybe just one key, maybe lots of keys) but you can't revoke it from the new service, only from GitHub, because the process of authorizing you to the new service was append-only.
It's not append-only. No one is suggesting that any new service must only pull keys from GitHub once and then it never changes. GitHub is just a convenient source to bootstrap from.
You might need to go into your new service (possibly through another factor like physical access or web admin) and manually revoke compromised keys.
I just don't think any of this is a reason to have a separate key for each service you use, that still seems rather unnecessary.
https://gist.github.com/sivel/c68f601137ef9063efd7 - uses AuthorizedKeysCommand to make a remote server the authoritative source of your SSH keys, so (if you wanted to) you could make GitHub your key provider.
You should use different keypairs per identity, and different secrets per service. However, when a service relies on public-key cryptography, there's no reason not to reuse the same keypair for different services.
If your private keys are stored on your local machine, chances are if one is compromised, all are compromised.
If you're following good security practices like...
* Using a strong passphrase on your private key(s)
* Never copying your private keys around between systems (especially not unencrypted)
* Using a hardware key management dongle
...then there is little to no _security_ risk in using one key for multiple services vs individual keys for each service. The threat model here is that an attacker is able to discover your private keys somehow. If the system holding the private key(s) is compromised, they can grab multiple keys just as easily as they can grab one.
Others have noted that there can be a slight _privacy_ risk to sharing your SSH public key across services. If you never want your accounts across different services to be correlated with each other, then yes, you would want a separate SSH keypair for each. But many of us use the same identity across services anyway as part of our personal brand so that point is moot for us.
I don't think using different keys per service or host buys you much in terms of security. Yes, an attacker that compromised your keys would have to brute-force your passphrase for N keys rather than one private key, but that just takes N times as long, not really an obstacle.
It would be better to use a hardware authenticator like a Yubikey to either generate a FIDO token-backed SSH key or a GPG key and use the gpg agent as your ssh agent. This way you get SSH keys that cannot reasonably be compromised by other means than physical attacks (someone steals your key and coerces you to reveal pin code).
The only issue I see with this is if/when you run up on someone with multiple keys, then you’re blindly taking all the keys and giving access to multiple computers.
github stripped the key names/annotations from .keys (for good reasons), so if you do that and you use one ssh key per machine, when you need to revoke a machine you won't easily know which key to remove from authorized_keys.
Keybase (or similar) would ideally be used for this instead, but they chose to go a very weird route for their tool, and are now disappearing completely eventually probably.