7 ms·

Does anyone know why github exposes user public keys ? Does it have any purpose?

enasterosophes 4y ago
"Exposes" is a strong word. Public keys are meant to be public. The only reason you might think twice about handing them over is they can de-anonymize you if you were practising identity hygiene. Having a public register of public keys makes it easy to give people access to your organization, CI/CD etc.
- cryptonector 4y ago
  Public keys are not meant to be public. They can be public in that making them public doesn't compromise the corresponding private keys. And generally making them public helps scale key management. There are cryptographic protocols where public keys are kept private. For example TLS with client certificates (the client's certificate gets sent encrypted to the server). Ditto SSHv2 (the client need not reveal all its public keys, and it does get to authenticate the server before revealing its identity and public keys).
  - enasterosophes 4y ago
    You're right, but my intention was to tackle unfounded nervousness, not to draft a technical document explaining all the ins and outs of keypair cryptography.
  - Reitet00 4y ago
    > For example TLS with client certificates (the client's certificate gets sent encrypted to the server). Hmm... I was under the impression that up until TLS 1.3 the client cert was sent in the clear during session negotiation...
    - cryptonector 4y ago
      Yes, you're right, in 1.3 it goes encrypted, while in <1.3 it goes in the clear.
- Galanwe 4y ago
  > "Exposes" is a strong word. Public keys are meant to be public That's a very strong overstatement. With this argument, you could argue that data leaks involving names, emails, etc are fine, because emails and names are meant to be public.
  - danw1979 4y ago
    Public keys are not PII though, unlike your real name.
    - kevincox 4y ago
      They can be once they are linked to your GitHub account which may have your real name.
- FatActor 4y ago
  Well, yeah, but I just got a chill realizing if I'm just dinking around trying to ssh into a random addresses that I'll be sending my public keys for auth which can be correlated. Not a big deal, but I forgot about that leak, so "expose" made me read further and be reminded that clearly I am not a blackhat, or any color hat for that matter.
MathMonkeyMan 4y ago
It's handy to allow my teammate onto my kubernetes cluster without having to ask him for his public key.
- ofrzeta 4y ago
  Where's the ssh server running in the cluster?
  - MathMonkeyMan 4y ago
    on each node
    - ofrzeta 4y ago
      Ok, and then the users have root permissions to interact with the containers? Forgive me for asking but I am thinking about solving similar problems (access to containers via ssh) .. or maybe I should use Teleport instead.
      - mschuster91 4y ago
        You usually only need this to do extremely low-level debugging in k8s, or to do generic system maintenance (e.g. OS upgrade). Your average devops person? They will be happy when given a kubeconfig file linked to a role allowing them "kubectl exec" access to the workloads.
        MathMonkeyMan 4y ago
        Good point. These are test clusters that we use to reproduce customer issues. They usually have three or even just one node. It is in no way a production environment.
jljljl 4y ago
Github allows you to sign commits with your SSH keys. Having the public keys available publicly means anyone can verify the signature: https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification https://docs.github.com/en/authentication/managing-commit-si...
throwawayapples 4y ago
Userify lets you import public keys from Github and Gitlab, which is handy.
chasil 4y ago
SSH keys can now be used to sign arbitrary content, so any github user with a published key is now able to publish verified content that can be verified offline. https://www.agwa.name/blog/post/ssh_signatures https://www.agwa.name/blog/post/ssh_signatures

"Exposes" is a strong word. Public keys are meant to be public. The only reason you might think twice about handing them over is they can de-anonymize you if you were practising identity hygiene. Having a public register of public keys makes it easy to give people access to your organization, CI/CD etc.

cryptonector 4y ago
Public keys are not meant to be public. They can be public in that making them public doesn't compromise the corresponding private keys. And generally making them public helps scale key management. There are cryptographic protocols where public keys are kept private. For example TLS with client certificates (the client's certificate gets sent encrypted to the server). Ditto SSHv2 (the client need not reveal all its public keys, and it does get to authenticate the server before revealing its identity and public keys).
- enasterosophes 4y ago
  You're right, but my intention was to tackle unfounded nervousness, not to draft a technical document explaining all the ins and outs of keypair cryptography.
- Reitet00 4y ago
  > For example TLS with client certificates (the client's certificate gets sent encrypted to the server). Hmm... I was under the impression that up until TLS 1.3 the client cert was sent in the clear during session negotiation...
  - cryptonector 4y ago
    Yes, you're right, in 1.3 it goes encrypted, while in <1.3 it goes in the clear.
Galanwe 4y ago
> "Exposes" is a strong word. Public keys are meant to be public That's a very strong overstatement. With this argument, you could argue that data leaks involving names, emails, etc are fine, because emails and names are meant to be public.
- danw1979 4y ago
  Public keys are not PII though, unlike your real name.
  - kevincox 4y ago
    They can be once they are linked to your GitHub account which may have your real name.
FatActor 4y ago
Well, yeah, but I just got a chill realizing if I'm just dinking around trying to ssh into a random addresses that I'll be sending my public keys for auth which can be correlated. Not a big deal, but I forgot about that leak, so "expose" made me read further and be reminded that clearly I am not a blackhat, or any color hat for that matter.

MathMonkeyMan 4y ago

It's handy to allow my teammate onto my kubernetes cluster without having to ask him for his public key.

ofrzeta 4y ago
Where's the ssh server running in the cluster?
- MathMonkeyMan 4y ago
  on each node
  - ofrzeta 4y ago
    Ok, and then the users have root permissions to interact with the containers? Forgive me for asking but I am thinking about solving similar problems (access to containers via ssh) .. or maybe I should use Teleport instead.
    - mschuster91 4y ago
      You usually only need this to do extremely low-level debugging in k8s, or to do generic system maintenance (e.g. OS upgrade). Your average devops person? They will be happy when given a kubeconfig file linked to a role allowing them "kubectl exec" access to the workloads.
      - MathMonkeyMan 4y ago
        Good point. These are test clusters that we use to reproduce customer issues. They usually have three or even just one node. It is in no way a production environment.

jljljl 4y ago

Github allows you to sign commits with your SSH keys. Having the public keys available publicly means anyone can verify the signature: https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification https://docs.github.com/en/authentication/managing-commit-si...

throwawayapples 4y ago

Userify lets you import public keys from Github and Gitlab, which is handy.

chasil 4y ago

SSH keys can now be used to sign arbitrary content, so any github user with a published key is now able to publish verified content that can be verified offline. https://www.agwa.name/blog/post/ssh_signatures https://www.agwa.name/blog/post/ssh_signatures