←back to thread

Sign arbitrary data with your SSH keys

(www.agwa.name)
637 points h1x | 7 comments | 13 Nov 21 09:13 UTC | HN request time: 0.661s | source | bottom
Show context
pizza ◴[13 Nov 21 10:03 UTC] No.29208734[source]▶
I get that they're "public" keys, but I was surprised to learn (and from somebody other than github themselves) that ssh public keys are just available at that github.com/username.keys URL (without there being an option to disable it, it seems?). Did most people already know that? Probably fine but just surprised. Just tried searching their authentication docs [0] and I don't get any results for "public key url" either

https://docs.github.com/en/authentication?query=public+key+u...

replies(26): >>29208748 #>>29208752 #>>29208754 #>>29208768 #>>29208790 #>>29208806 #>>29208828 #>>29208856 #>>29208877 #>>29208909 #>>29208990 #>>29209073 #>>29209103 #>>29209113 #>>29209243 #>>29209399 #>>29209634 #>>29210045 #>>29210085 #>>29210460 #>>29211355 #>>29211357 #>>29211783 #>>29212241 #>>29212499 #>>29213083 #
diggan ◴[13 Nov 21 10:39 UTC] No.29208877[source]▶
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.

replies(4): >>29208947 #>>29209520 #>>29209813 #>>29211070 #
Hendrikto ◴[13 Nov 21 10:57 UTC] No.29208947[source]▶
Shouldn‘t you be using different keys for different services though? What you are doing sounds like bad practice.
replies(4): >>29209106 #>>29209133 #>>29209308 #>>29211664 #
themacguffinman ◴[13 Nov 21 11:36 UTC] No.29209106[source]▶
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.
replies(1): >>29209294 #
1. dmurray ◴[13 Nov 21 12:26 UTC] No.29209294[source]▶
> 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.

replies(4): >>29209610 #>>29210141 #>>29210468 #>>29212555 #
2. keeganpoppen ◴[13 Nov 21 13:39 UTC] No.29209610[source]▶
but this is just a problem with copying the keys in general-- it has nothing to do with github specifically at all
3. ◴[13 Nov 21 14:53 UTC] No.29210141[source]▶
4. judge2020 ◴[13 Nov 21 15:35 UTC] No.29210468[source]▶
Solutions:

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.

https://github.com/ierror/ssh-permit-a38 - 3 years old but that's not necessarily an issue

https://github.com/gravitational/teleport

5. themacguffinman ◴[13 Nov 21 19:37 UTC] No.29212555[source]▶
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?

replies(1): >>29216850 #
6. dmurray ◴[14 Nov 21 12:36 UTC] No.29216850[source]▶
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.
replies(1): >>29216975 #
7. themacguffinman ◴[14 Nov 21 13:08 UTC] No.29216975{3}[source]▶
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.