13 ms·

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

by pizza 5y ago

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+url https://docs.github.com/en/authentication?query=public+key+u...

whirlwin 5y ago
This can be a security risk if you're using the same SSH keypair for other things, and you're using a less secure algorithm than RSA or ED or similar. Anyone doing a bit of research about you might discover a vulnerable host for which the vulnerable algorithm keypair might be targeted
- teekert 5y ago
  When that happens you were relying on security by obscurity. It’s a hack waiting to happen. This, at least creates awareness and forces secure keys. But you are right, it may be a security risk, but only when it already was (arguably it was smaller).
erk__ 5y ago
And similarly GPG keys are at github.com/username.gpg
- giaour 5y ago
  This seems more legit. If a user is signing their commits, other users should have access to their public keys in order to verify the signatures.
  - megous 5y ago
    Usefulness of that access from the same service you're getting the signed commit from is close to nil. Public keys should be distributed in a trustworthy way.
mynameismon 5y ago
Is it just me or can we not see out public keys in the settings page by design?
franga2000 5y ago
Yeah, I use that more than I really should - it's way easier to slightly change the URL in my already open github tab than scouring my disk for my or someone else's keys. New versions of Ubuntu Server will actually let you import keys from GitHub during setup. Really handy, although obviously not something for highly secure environments.
archseer 5y ago
It's a very convenient way of distributing your public key.
zaik 5y ago
They do seem to strip the name of the keys which I am thankful for.
GauntletWizard 5y ago
It's one of those tricks that's not super well known but a decent few know it - The Ubuntu server installer will ask if you want to import your ssh keys from Github, for example, and there was a Show HN[1] with a cool trick[2] that took advantage of this information. [1]https://news.ycombinator.com/item?id=10004678 https://news.ycombinator.com/item?id=10004678 [2]https://github.com/FiloSottile/whoami.filippo.io https://github.com/FiloSottile/whoami.filippo.io
deleted 5y ago
[deleted]
raesene9 5y ago
I think it's this feature that Ubuntu integrates into their install process, so you can add your GH keys for SSH auth. which is v.useful.
- politelemon 5y ago
  Could you expand on this a bit. Where does Ubuntu ask for your github username?
  - mercora 5y ago
    ive seen it few days ago while using the installer on the netinstall iso.. its an option to import keys from github while creating the regular user...
  - mrena 5y ago
    When installing new system, there is an option to input your github/launchpad username http://manpages.ubuntu.com/manpages/bionic/man1/ssh-import-id.1.html http://manpages.ubuntu.com/manpages/bionic/man1/ssh-import-i...
  - raesene9 5y ago
    Where I see it is in the interactive installer for Ubuntu server, there's a screen that asks if you want to install SSH on the host and then it asks if you want to import keys from GH. You pass it a GH user name and it lists the keys to be imported.
diggan 5y ago
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 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.
- Hendrikto 5y ago
  Shouldn‘t you be using different keys for different services though? What you are doing sounds like bad practice.
  - themacguffinman 5y ago
    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.
    - dmurray 5y ago
      > 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.
      - keeganpoppen 5y ago
        but this is just a problem with copying the keys in general-- it has nothing to do with github specifically at all
surfsvammel 5y ago
It’s very handy. I use it often. Whenever I, or someone else, need to add my public key to a server somewhere, that’s where I get it from.
- Hendrikto 5y ago
  Are you guys really using one SSH key for all services? That‘s really bad practice.
  - deleted 5y ago
    [deleted]
  - throwaway894345 5y ago
    You can put multiple SSH keys on GitHub.
    - Hendrikto 5y ago
      Not what I am talking about. I am talking about using the same key pair for two different things. E.g. GitHub and GitLab
      - chousuke 5y ago
        Using different keys for different services is overkill most of the time. Generally you need to have one key per host that you use (or per any storage location). You can use separate keys for separate services is if you for eg. privacy reasons don't want to associate the same identity with both services, but that's a personal choice, not something that improves security.
      - kenmacd 5y ago
        I am. My ssh key is my gpg auth key. It's stored on my yubikey requiring a touch each time I use it. I use the same gpg key for talking to anyone, so why wouldn't I do the same with my ssh key? I suppose I could try to build a workflow around host-specific keys somehow derived from my auth key… but I'd need some reason to do so.
throwaway894345 5y ago
Even cooler, you can tell cloud-init to download your SSH keys from GitHub and drop them in the user's ~/.ssh/authorized_keys. Something like this IIRC: users: - name: foo ssh_authorized_keys: [gh:foo]
- flir 5y ago
  That was sarcasm, right? (Genuine question). 'cos that sounds like a bad idea to me, and if it's not a bad idea, I'd like to understand why. Doesn't doing this mean you trust github implicitly?
  - drran 5y ago
    GitHub can alter the CODE. Why it should play with just a key? If GitHub wants to pwn the whole world, it can do it right now.
    - flir 5y ago
      Can't argue with that, except to say "because it's bad, lets make it worse" doesn't feel like a good rule of thumb.
      - deleted 5y ago
        [deleted]
    - fortran77 5y ago
      Well, github will already shut down repositories that contain words that they deem unacceptable. So they are doing it now... https://news.ycombinator.com/item?id=9966118 https://news.ycombinator.com/item?id=9966118
      - judge2020 5y ago
        GH specifically going out of their way to falsify keys of a user would be a much bigger breach of trust than just shutting down repos. They know ssh-import-id-gh is a thing and people use it.
tomxor 5y ago
I had a different concern... if people eventually start to use SSH keys to sign git commits, (as the article suggests will soon be possible), people can't validate github commit sigs with github public keys directly at one point in time... because if one is compromised, so is the other. The only way github could be used as key distribution for this purpose would be if individuals take (and keep) a copy of every public key they are interested for future verification in-case an attacker changes it. But then I guess any public key distribution system has this problem??
- pas 5y ago
  Ideally GitHub or any key distribution server just works as a dumb registry, the trust should flow from different systems. Of course in practice people just rely on the registry anyway.
- southerntofu 5y ago
  Bootstrapping is always a harder problem. But for updates, guix git authenticate [0] has definitely solved the problem. The idea is if you specify a certain commit that serves as a trust anchor, the .guix-authorizations file at that commit represents the public keys allowed to sign commits from that point: the file can be amended only by an already-approved key. So if the repo has that file, and as long as you don't allow history rewrite when pulling (disabled by default), you can be pretty confident all commits have been signed only by authorized keys from the point you checked out initially. About bootstrapping, several strategies are possible: - [crev](https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev) is an alternative (not PGP/SSH based) web of trust for vetting code - [radicle](https://radicle.xyz/ https://radicle.xyz/) is a p2p forge to do away entirely with web-based centralized forges (like github) - we could imagine a sort of public-key-addressed DHT where a forge (such a Github) advertises the public keys of its members, for example based on IPNS (although a history-preserving system would be better) - of course source-based distros like NixOS and GNU/guix are also a very good answer about bootstrapping trust in the code you run ; guix in particular does intensive research and development about bootstrappability and reproducibility [1] which you can read about on their blog [2] Shameless plug: i wrote an article earlier this year about some of the challenges surrounding decentralized forging: https://staticadventures.netlib.re/blog/decentralized-forge/ https://staticadventures.netlib.re/blog/decentralized-forge/ [0] https://guix.gnu.org/en/blog/2020/securing-updates/ https://guix.gnu.org/en/blog/2020/securing-updates/ [1] I'm personally really amazed and slightly disappointed by both: they're really cool on paper, but although guix has a much better CLI UX than nix (and in my opinion Guile Scheme is much easier than nix programming language), both have very cryptic errors [2] https://guix.gnu.org/en/blog/ https://guix.gnu.org/en/blog/
Edmond 5y ago
>I get that they're "public" keys From your quote around "public", I presume you think there is some sense in which they're not really public? They are and should ALWAYS be considered PUBLIC. If you find yourself ever crafting a security solution where public keys somehow need to be private or secret, go back to the drawing board or reach out to someone with serious expertise. There are cases where information on a certificate (which is associated with a public key)may indeed need to be protected, in that case you need to implement an information mask (via hashing) that can protect the private information, we had to do something similar with Certisfy.com certificates. But public keys should be considered public without exceptions.
- numair 5y ago
  > If you find yourself ever crafting a security solution where public keys somehow need to be private or secret, go back to the drawing board or reach out to someone with serious expertise. I know you’re taking the “strict teacher” approach with your comment, but you’re totally wrong. And the reason you’re wrong is, security doesn’t equal privacy. But for the “average person,” security does equal privacy, or should, so they find systems that could potentially expose their identity to be “insecure.” In this particular case, there have been past examples of using keys to fingerprint users without their consent. Yes, it’s been super edge-case and proof-of-concept, but for a lot of people — and perhaps more importantly, in a lot of jurisdictions — leaving a personal identifier sitting around like this (without ever informing the user!) is the very opposite of a best practice. The end result is, you should only have a key on GitHub that isn’t used anywhere else. That’s what I do, and I’m sure lots of us on this comment thread do, but there’s definitely lots of My First Coding Bootcamp people who were guided through their GitHub account installations who might not have been aware that these are keys that shouldn’t be reused elsewhere. I would have a very different view on this if GitHub had been explicit about the use of registered keys for other services. That’s a GREAT concept, but I’m not going to trust a company with that business when they’ve just backdoored themselves into it without asking for permission. And the problem for them is, in this particular situation you need the weird paranoid privacy crowd on your side for it to work.
  - Gargyle 5y ago
wyc 5y ago
We've implemented a DID method based on this! https://github.com/spruceid/ssi/tree/main/did-webkey https://github.com/spruceid/ssi/tree/main/did-webkey
- southerntofu 5y ago
  How does it work from a client perspective? Are there any browser (or browser plugin) supporting it yet? On paper it sounds pretty cool, i would dare say the only interesting application for DID i've heard so far :)
OJFord 5y ago
Why would you want to disable it? They're not 'scare-quote' public, they're just public - analogous (kind of craply but workably) to 'distributing' your face, but not your passport/driving licence/etc. The private key part is secret of course, never shared (that's where the analogy above breaks) but the public part is fine and desirable for everyone to have access to - that's how they verify that you signed something with your private key, how they encrypt a secret message to you.
- Djrhfbfnsks 5y ago
  Because they may be used to learn the identity of an otherwise pseudoanonymous github account if one uses the same keys with another account that is tied to his real identity.
  - pmontra 5y ago
    One key per service. I've got a directory full of them and a long .ssh/config
  - OJFord 5y ago
    If the account is intended to be anonymous, it should have its own keypair not shared with the real identity (or other independently anonymous account). I say this regardless of whether public keys are being.. publicised. User database could be leaked, say, or public keys visible to employees/logged. OpenSSH literally refers to them as 'identities' - if you're trying to be anonymous/anon w.r.t. another it goes without saying that you need to not use the same identity!
- b3morales 5y ago
  I don't much want my face automatically associated with my GitHub (or other) account, either.
junon 5y ago
Why shouldn't they be? Public keys are perfectly safe to be shared publicly. Otherwise RSA would have very limited value.
elric 5y ago
It's a good idea to keep your public keys private. You can do this by using a different key for each purpose, and by explicitly configuring (in ~/.ssh/config) which key to use for which purpose. By default, the ssh client will try to each of your public keys to connect to any given server, which naughty servers can effectively use to enumerate your identities. Services like Github really shouldn't publish these keys without consent. One could argue they're really PII and subject to privacy laws ..
- Gargyle 5y ago
  Maybe this needs more precise wording. Like ingress/signature key but more compressed instead of public key. Or peer key. Any nice ideas?
  - elric 5y ago
    That's a good point. The wording makes sense from a cryptographic point of view, but it doesn't really convey the full meaning outside of that context.
z3t4 5y ago
At least they have filtered out the comment part, so that e-mail addresses and computer names can't be scraped.
butterknife 5y ago
Do you hide your main door keyway?
daitangio 5y ago
It is the magic behind fast ubuntu server install: if you provide your github username, the cloud installer will pump keys on your default user and you will be able to ssh to the new server without a display.
_hyn3 5y ago
This seems to have been public for quite a while. It's also how Userify.com imports public keys from Github.com for years (and also imports from Gitlab.com, which copied Github's approach.) For some reason, Userify itself doesn't also allow easy export of its users' public keys.
morpheuskafka 5y ago
The Ubuntu Server installer has used this trick for a while to allow people to get their SSH keys imported during initial setup.
deleted 5y ago
[deleted]
jokethrowaway 5y ago
That's how I give ssh access to collaborators on VPS, add people to blackbox in git repos or share encrypted files with them. It's pretty great. I forgot where I learnt about it; I think I was inquiring how NameCoin was able to gift their cryptocurrency to GitHub developers with more than 50 followers.
whateveracct 5y ago
Just use a public key for github alone. I tend to use a public key per-application.

by pizza 5y ago

whirlwin 5y ago

This can be a security risk if you're using the same SSH keypair for other things, and you're using a less secure algorithm than RSA or ED or similar. Anyone doing a bit of research about you might discover a vulnerable host for which the vulnerable algorithm keypair might be targeted

teekert 5y ago
When that happens you were relying on security by obscurity. It’s a hack waiting to happen. This, at least creates awareness and forces secure keys. But you are right, it may be a security risk, but only when it already was (arguably it was smaller).

erk__ 5y ago

And similarly GPG keys are at github.com/username.gpg

giaour 5y ago
This seems more legit. If a user is signing their commits, other users should have access to their public keys in order to verify the signatures.
- megous 5y ago
  Usefulness of that access from the same service you're getting the signed commit from is close to nil. Public keys should be distributed in a trustworthy way.

mynameismon 5y ago

Is it just me or can we not see out public keys in the settings page by design?

franga2000 5y ago

Yeah, I use that more than I really should - it's way easier to slightly change the URL in my already open github tab than scouring my disk for my or someone else's keys. New versions of Ubuntu Server will actually let you import keys from GitHub during setup. Really handy, although obviously not something for highly secure environments.

archseer 5y ago

It's a very convenient way of distributing your public key.

zaik 5y ago

They do seem to strip the name of the keys which I am thankful for.

GauntletWizard 5y ago

It's one of those tricks that's not super well known but a decent few know it - The Ubuntu server installer will ask if you want to import your ssh keys from Github, for example, and there was a Show HN[1] with a cool trick[2] that took advantage of this information. [1]https://news.ycombinator.com/item?id=10004678 https://news.ycombinator.com/item?id=10004678 [2]https://github.com/FiloSottile/whoami.filippo.io https://github.com/FiloSottile/whoami.filippo.io

deleted 5y ago

[deleted]

raesene9 5y ago

I think it's this feature that Ubuntu integrates into their install process, so you can add your GH keys for SSH auth. which is v.useful.

politelemon 5y ago
Could you expand on this a bit. Where does Ubuntu ask for your github username?
- mercora 5y ago
  ive seen it few days ago while using the installer on the netinstall iso.. its an option to import keys from github while creating the regular user...
- mrena 5y ago
  When installing new system, there is an option to input your github/launchpad username http://manpages.ubuntu.com/manpages/bionic/man1/ssh-import-id.1.html http://manpages.ubuntu.com/manpages/bionic/man1/ssh-import-i...
- raesene9 5y ago
  Where I see it is in the interactive installer for Ubuntu server, there's a screen that asks if you want to install SSH on the host and then it asks if you want to import keys from GH. You pass it a GH user name and it lists the keys to be imported.

diggan 5y ago

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

Hendrikto 5y ago
Shouldn‘t you be using different keys for different services though? What you are doing sounds like bad practice.
- themacguffinman 5y ago
  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.
  - dmurray 5y ago
    > 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.
    - keeganpoppen 5y ago
      but this is just a problem with copying the keys in general-- it has nothing to do with github specifically at all

surfsvammel 5y ago

It’s very handy. I use it often. Whenever I, or someone else, need to add my public key to a server somewhere, that’s where I get it from.

Hendrikto 5y ago
Are you guys really using one SSH key for all services? That‘s really bad practice.
- deleted 5y ago
  [deleted]
- throwaway894345 5y ago
  You can put multiple SSH keys on GitHub.
  - Hendrikto 5y ago
    Not what I am talking about. I am talking about using the same key pair for two different things. E.g. GitHub and GitLab
    - chousuke 5y ago
      Using different keys for different services is overkill most of the time. Generally you need to have one key per host that you use (or per any storage location). You can use separate keys for separate services is if you for eg. privacy reasons don't want to associate the same identity with both services, but that's a personal choice, not something that improves security.
    - kenmacd 5y ago
      I am. My ssh key is my gpg auth key. It's stored on my yubikey requiring a touch each time I use it. I use the same gpg key for talking to anyone, so why wouldn't I do the same with my ssh key? I suppose I could try to build a workflow around host-specific keys somehow derived from my auth key… but I'd need some reason to do so.

throwaway894345 5y ago

Even cooler, you can tell cloud-init to download your SSH keys from GitHub and drop them in the user's ~/.ssh/authorized_keys. Something like this IIRC: users: - name: foo ssh_authorized_keys: [gh:foo]

flir 5y ago
That was sarcasm, right? (Genuine question). 'cos that sounds like a bad idea to me, and if it's not a bad idea, I'd like to understand why. Doesn't doing this mean you trust github implicitly?
- drran 5y ago
  GitHub can alter the CODE. Why it should play with just a key? If GitHub wants to pwn the whole world, it can do it right now.
  - flir 5y ago
    Can't argue with that, except to say "because it's bad, lets make it worse" doesn't feel like a good rule of thumb.
    - deleted 5y ago
      [deleted]
  - fortran77 5y ago
    Well, github will already shut down repositories that contain words that they deem unacceptable. So they are doing it now... https://news.ycombinator.com/item?id=9966118 https://news.ycombinator.com/item?id=9966118
    - judge2020 5y ago
      GH specifically going out of their way to falsify keys of a user would be a much bigger breach of trust than just shutting down repos. They know ssh-import-id-gh is a thing and people use it.

tomxor 5y ago

I had a different concern... if people eventually start to use SSH keys to sign git commits, (as the article suggests will soon be possible), people can't validate github commit sigs with github public keys directly at one point in time... because if one is compromised, so is the other. The only way github could be used as key distribution for this purpose would be if individuals take (and keep) a copy of every public key they are interested for future verification in-case an attacker changes it. But then I guess any public key distribution system has this problem??

pas 5y ago
Ideally GitHub or any key distribution server just works as a dumb registry, the trust should flow from different systems. Of course in practice people just rely on the registry anyway.
southerntofu 5y ago
Bootstrapping is always a harder problem. But for updates, guix git authenticate [0] has definitely solved the problem. The idea is if you specify a certain commit that serves as a trust anchor, the .guix-authorizations file at that commit represents the public keys allowed to sign commits from that point: the file can be amended only by an already-approved key. So if the repo has that file, and as long as you don't allow history rewrite when pulling (disabled by default), you can be pretty confident all commits have been signed only by authorized keys from the point you checked out initially. About bootstrapping, several strategies are possible: - [crev](https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev) is an alternative (not PGP/SSH based) web of trust for vetting code - [radicle](https://radicle.xyz/ https://radicle.xyz/) is a p2p forge to do away entirely with web-based centralized forges (like github) - we could imagine a sort of public-key-addressed DHT where a forge (such a Github) advertises the public keys of its members, for example based on IPNS (although a history-preserving system would be better) - of course source-based distros like NixOS and GNU/guix are also a very good answer about bootstrapping trust in the code you run ; guix in particular does intensive research and development about bootstrappability and reproducibility [1] which you can read about on their blog [2] Shameless plug: i wrote an article earlier this year about some of the challenges surrounding decentralized forging: https://staticadventures.netlib.re/blog/decentralized-forge/ https://staticadventures.netlib.re/blog/decentralized-forge/ [0] https://guix.gnu.org/en/blog/2020/securing-updates/ https://guix.gnu.org/en/blog/2020/securing-updates/ [1] I'm personally really amazed and slightly disappointed by both: they're really cool on paper, but although guix has a much better CLI UX than nix (and in my opinion Guile Scheme is much easier than nix programming language), both have very cryptic errors [2] https://guix.gnu.org/en/blog/ https://guix.gnu.org/en/blog/

Edmond 5y ago

>I get that they're "public" keys From your quote around "public", I presume you think there is some sense in which they're not really public? They are and should ALWAYS be considered PUBLIC. If you find yourself ever crafting a security solution where public keys somehow need to be private or secret, go back to the drawing board or reach out to someone with serious expertise. There are cases where information on a certificate (which is associated with a public key)may indeed need to be protected, in that case you need to implement an information mask (via hashing) that can protect the private information, we had to do something similar with Certisfy.com certificates. But public keys should be considered public without exceptions.

numair 5y ago
> If you find yourself ever crafting a security solution where public keys somehow need to be private or secret, go back to the drawing board or reach out to someone with serious expertise. I know you’re taking the “strict teacher” approach with your comment, but you’re totally wrong. And the reason you’re wrong is, security doesn’t equal privacy. But for the “average person,” security does equal privacy, or should, so they find systems that could potentially expose their identity to be “insecure.” In this particular case, there have been past examples of using keys to fingerprint users without their consent. Yes, it’s been super edge-case and proof-of-concept, but for a lot of people — and perhaps more importantly, in a lot of jurisdictions — leaving a personal identifier sitting around like this (without ever informing the user!) is the very opposite of a best practice. The end result is, you should only have a key on GitHub that isn’t used anywhere else. That’s what I do, and I’m sure lots of us on this comment thread do, but there’s definitely lots of My First Coding Bootcamp people who were guided through their GitHub account installations who might not have been aware that these are keys that shouldn’t be reused elsewhere. I would have a very different view on this if GitHub had been explicit about the use of registered keys for other services. That’s a GREAT concept, but I’m not going to trust a company with that business when they’ve just backdoored themselves into it without asking for permission. And the problem for them is, in this particular situation you need the weird paranoid privacy crowd on your side for it to work.
- Gargyle 5y ago

wyc 5y ago

We've implemented a DID method based on this! https://github.com/spruceid/ssi/tree/main/did-webkey https://github.com/spruceid/ssi/tree/main/did-webkey

southerntofu 5y ago
How does it work from a client perspective? Are there any browser (or browser plugin) supporting it yet? On paper it sounds pretty cool, i would dare say the only interesting application for DID i've heard so far :)

OJFord 5y ago

Why would you want to disable it? They're not 'scare-quote' public, they're just public - analogous (kind of craply but workably) to 'distributing' your face, but not your passport/driving licence/etc. The private key part is secret of course, never shared (that's where the analogy above breaks) but the public part is fine and desirable for everyone to have access to - that's how they verify that you signed something with your private key, how they encrypt a secret message to you.

Djrhfbfnsks 5y ago
Because they may be used to learn the identity of an otherwise pseudoanonymous github account if one uses the same keys with another account that is tied to his real identity.
- pmontra 5y ago
  One key per service. I've got a directory full of them and a long .ssh/config
- OJFord 5y ago
  If the account is intended to be anonymous, it should have its own keypair not shared with the real identity (or other independently anonymous account). I say this regardless of whether public keys are being.. publicised. User database could be leaked, say, or public keys visible to employees/logged. OpenSSH literally refers to them as 'identities' - if you're trying to be anonymous/anon w.r.t. another it goes without saying that you need to not use the same identity!
b3morales 5y ago
I don't much want my face automatically associated with my GitHub (or other) account, either.

junon 5y ago

Why shouldn't they be? Public keys are perfectly safe to be shared publicly. Otherwise RSA would have very limited value.

elric 5y ago

It's a good idea to keep your public keys private. You can do this by using a different key for each purpose, and by explicitly configuring (in ~/.ssh/config) which key to use for which purpose. By default, the ssh client will try to each of your public keys to connect to any given server, which naughty servers can effectively use to enumerate your identities. Services like Github really shouldn't publish these keys without consent. One could argue they're really PII and subject to privacy laws ..

Gargyle 5y ago
Maybe this needs more precise wording. Like ingress/signature key but more compressed instead of public key. Or peer key. Any nice ideas?
- elric 5y ago
  That's a good point. The wording makes sense from a cryptographic point of view, but it doesn't really convey the full meaning outside of that context.

z3t4 5y ago

At least they have filtered out the comment part, so that e-mail addresses and computer names can't be scraped.

butterknife 5y ago

Do you hide your main door keyway?

daitangio 5y ago

It is the magic behind fast ubuntu server install: if you provide your github username, the cloud installer will pump keys on your default user and you will be able to ssh to the new server without a display.

_hyn3 5y ago

This seems to have been public for quite a while. It's also how Userify.com imports public keys from Github.com for years (and also imports from Gitlab.com, which copied Github's approach.) For some reason, Userify itself doesn't also allow easy export of its users' public keys.

morpheuskafka 5y ago

The Ubuntu Server installer has used this trick for a while to allow people to get their SSH keys imported during initial setup.

deleted 5y ago

[deleted]

jokethrowaway 5y ago

That's how I give ssh access to collaborators on VPS, add people to blackbox in git repos or share encrypted files with them. It's pretty great. I forgot where I learnt about it; I think I was inquiring how NameCoin was able to gift their cryptocurrency to GitHub developers with more than 50 followers.

whateveracct 5y ago

Just use a public key for github alone. I tend to use a public key per-application.