Sign arbitrary data with your SSH keys

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

[1]https://news.ycombinator.com/item?id=10004678 [2]https://github.com/FiloSottile/whoami.filippo.io

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.

http://manpages.ubuntu.com/manpages/bionic/man1/ssh-import-i...

    users:
      - name: foo
        ssh_authorized_keys: [gh:foo]

I am talking about using the same key pair for two different things. E.g. GitHub and GitLab

You'd need several prerequisites for that to actually increase security, i.e. not using an ssh-agent (required password for every key prompt) and encrypting them at rest

Otherwise you'll leak all your keys as soon as any attack vector is utilized such as hostile host siphoning from the ssh-agent forwarding or filesystem access.

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

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.

https://github.com/spruceid/ssi/tree/main/did-webkey

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

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.

Doesn't doing this mean you trust github implicitly?

Its a big privacy leak, not a big security leak.

Your Pubkey can be used to cross-match multiple identities. Example: You have different coding personae. One that is activist, one that is company-peon. Different accounts, same SSH pubkey in Github or other server with publicly listed pubkeys --> Same person confirmed.

As a result of this the information can be used to target each of the identities in a more precise manner. On the human layer of the security side: New phishing/deception/blackmail vectors.

On the organizational layer: we have to target these keybearer devices now.

Maybe it even helps in a cryptanalytic way in some weird exotic scenario but not substantially.

And of course separation of concerns if you have different keybearer devices.

(Also the famous Keysticks are a nice solution to that organizationally but they are an additional risk for big scale attacks by having biased RNGs. In the end its hardware and audits are just a voluntary thing by corps. They can always choose to hide things from auditors or do a compromised batch at their mercy.)

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.

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) is an alternative (not PGP/SSH based) web of trust for vetting code

- [radicle](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/

[0] 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/

On paper it sounds pretty cool, i would dare say the only interesting application for DID i've heard so far :)

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.

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.

If your private keys are stored on your local machine, chances are if one is compromised, all are compromised.

Your answer actually stumbled into the reason why so-called "public" keys may not want to be published. There are 2 different objectives:

- public key as part of a encryption pair : publishing this is no big deal as it shouldn't compromise SHA256 private key for decryption. So "security by obscurity" isn't necessary.

- public key as an identity for metadata/tracing : some may not want public keys to be known for correlation ... e.g. That's why Bitcoin wallet software generates new public+private keys for each transaction even though exposing a public key doesn't compromise ECDSA encryption.

How to practically manage this, with git in particular.

To say it another way. Private means, only I know it. And public just means anything but private. With varying degrees of how public something might be.

Funnily enough that's very different from what ordinary people think private and public is.

Private is everything they didn't explicitly intended to be visible to all the people on the internet and public is only that.

Your SSH public key is really the least of your identifiable information you’d be worried about because that’s the easiest to create a unique key for GitHub.

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!

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

i see that the docs are missing info on ssh there still. i will update this since with 2.34 you can also specify a ssh publik key literally in this variable or point it to a file with it.

Doesn’t GitHub only allow a key to be associated with a single account? After all, they use it to authenticate SSH pushes.

The privacy worry here is a little more esoteric —- your SSH public key could be used to cross match your GitHub user account with an account on a different system.

https://news.ycombinator.com/item?id=9966118

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.

  ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCalPlcbQUWX5caNedbKuWxAOUG+wFU2jtPUXmAcUDTIUgNz9JeW7cOAH1FPAcouIBM/0e48hdswSB2XHR0yHj3HvGx2KfB1lsd+FxXRR+dGPzO3WiMHXHdKogmHilk9U1ztwEFoZAkXuxvykv+Sn16j/xHXgFHdx5IDl/jyT5/IEIZHiePQqPYgptea/kXDiQGClMcT5V1bczCQH5tIcXdSKHhXn3oV1IAd79FpznmeCMALsyS4MUeU7uSx32PknIpgev64aMFgZItJUanqaeABuc9mcGNgHLBhBdO+gCOwBnwd+7boKmRawvMnEwsoznN9elr4FeBB81mBRnc6Q53 numair

Related, VPN users can easily be fingerprinted if they are assigned unique certificates for each account.

I shouldn’t have phrased my comment as a question: a former employer required that I use different GH accounts for different purposes, and it was a hassle to get local repositories to use the correct keypair. I recall being annoyed at GH at the time, but since your SSH key is used as an authentication mechanism on SSH pushes, they really can’t let a keypair be associated with multiple accounts.

Curious why you think it would be a bad idea to trust Github/Gitlab to warrant your identity.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCssSd91viJEmUQNx28L6JifYcGwTNEkLnmvZvdNxWxdTCrKwPEBVdlLooN90QugL/mJVwcWj9qsnOLbcoVaJlqMppY8UYlHP6OnGwKRGkpPdbKHnBA+Rrg7r8GUwdLW/PvI8DWhEPXzzWvrCNiESJWVdSCT2bTfAA3CQuPnL9cr5hcpw0i1jf7PBXRiVw2E2133KhEr91xNMH/jXh4jrly3J+kmBEmJcrkHNrHj0O8Ml+PmVQknq+tYT1DivnE2dxHoMkfdP0xP9yV9s0+7/JhU+tnXJ2+kaIOSpOOmhBPyjNYO6wkNvQh3aYzKrtcoOWPO2y56sfw9Uqlbpyr1ZU1 Gargyle

Nonsense. Would you say the same thing about a password? Would you make the same comment about a conversation over a messaging service? This is a configuration detail of an account setting -- not a blog post.

Privacy is not binary; there are many shades of grey. It is surprising that this is made public and while it is not necessarily wrong to provide this service (I'm fine with it; I see the utility) it is also reasonable to ask for a way to opt out.

In order to compromise your private key the attacker would have to gain access to your local machine, in which case all of your private keys are compromised.

You should use different key pairs per client, so that if one client machine is compromised you don’t have to change keys on the rest of them.

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

Just because the functional security of a system isn't dependent on the exposure of a public component doesn't mean it should implicitly be shared.

I agree. The way that I deal with this is as follows:

In my ~/.ssh/config I have content that looks like:

    Host gh-company-a
            User git
            HostName github.com
            IdentityFile ~/.ssh/id_ed25519_company_a

    Host gh-acme-inc
            User git
            HostName github.com
            IdentityFile ~/.ssh/id_ed25519_acme_inc

    Host gh-sponges-corp
            User git
            HostName github.com
            IdentityFile ~/.ssh/id_ed25519_sponges_corp

    git clone git@github.com:companya/foo.git

    git clone gh-company-a:companya/foo.git

    git clone git@github.com:acmeinc/baz.git

    git clone gh-acme-com:acmeinc/baz.git

With this way of doing it, the correct key pair gets used both for the initial clone and for subsequent pulls and pushes.

I suppose I could make a wrapper program that would take care of the substitution for me, to further reduce the amount of hassle. In fact I might end up doing that. I already have a few wrapper programs for various git commands.

Here's my ed key though.

  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIN3sRdLQYzhroFcUsId9X2xS1Um9bP0E+FiuiO5/qF5W oehpr

For example, to access secure areas of my network, you need to access the management plane first, with a separately managed system. Look at how GCP manages ssh keys for web consoles as another example.

Passwords are secrets. Public keys are not. So the comparison doesn’t work.

> Would you make the same comment about a conversation over a messaging service?

If it was a public messaging service like HN, or public comments on Twitter or Facebook, then yes.

> This is a configuration detail of an account setting -- not a blog post.

We could be here all day and night saying what this is or isn’t but it doesn’t address the point I was making. The moment you create a GitHub account you start leaking far more sensitive data than your public keys. Data that is far harder to create anonymously (unlike your SSH keys). Thus if privacy is a concern then you shouldn’t be using GitHub in the first place. Even git version control itself leaks information about you.

> Privacy is not binary; there are many shades of grey.

Ironic you state that when you’re the one applying privacy in a binary way. I’m saying the SSH public keys are a lower risk than other details you share in GitHub. Not that it’s a zero or 100% bad thing, which is the only pidgin holes you’re allowing for this discussion.

> It is surprising that this is made public and while it is not necessarily wrong to provide this service (I'm fine with it; I see the utility) it is also reasonable to ask for a way to opt out.

That’s literally the point I’ve been making.

If you agree that said platforms leak lots of other identifiable data (which you seam to) then thus it is a fair statement to say GitHub hiding public keys do little to enhance your privacy. And thus one can reasonably conclude that privacy argument doesn’t really hold with regards to SSH keys.

I’m happy to agree that it’s bad UX and probably should be advertised better so people are aware they should follow the (in my opinion best practice) of using a unique SSH key for GitHub.

Some platforms don’t publish users lists but it’s often the same platforms that like to post headline figures about their user base so I suspect not publishing user lists is more about a company being able to exaggerate its worth rather than privacy. Especially when those same platforms readily publish user names in every format aside one consolidated list.

In short, if a piece of information isn’t available on a social platform, or is frowned upon scraping, then odds are it’s more likely financially motivated than it is down to privacy. Given these same companies typically make their money from you handing over your data in the first place it would be naive to think they really care about your privacy.

https://therecord.media/security-agencies-leak-sensitive-dat...

   IdentitiesOnly yes

Otherwise all your public keys will be tried regardless.

While some may be fine having public keys dissiminated publicly, other github users would prefer keeping this data private, as it can be used for looking up their real identities.

The whole intention was to raise attention to a less often mentioned part of the information github exposes about accounts.

The parents quote I think is illustrative

> But for the “average person,” security does equal privacy, or should, so they find systems that could potentially expose their identity to be “insecure.”

And I’m not trying to pile on here, because I sympathize with that sentiment of “should”. But I think the two issues that make that never a real possibility are 1) privacy is actually a harder problem to solve than security and 2) companies aren’t incentivized to provide privacy.

Anything you provide online should by default be assumed to end up public, and as much as we might not want that, we all really need to assume that.

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

From the privacy perspective, they are PII. You should not publish them or link them to any information.

"Public" is a very overloaded word.

Edit If course you mean the new signing feature which will come to git and GitHub in the future. Sorry

Public keys should be distributed in a trustworthy way.

Also, plenty of people collaborate in private on GitHub. It has free private collaboration these days, not to mention.. paid. While it never strongly irked me that SSH public keys are visible, it’s not really that obvious. And I don’t buy the “but it has public in the name!” bit either. Sure, it’s not made to be confidential, but that doesn’t mean it should be published indiscriminately. I mean, I’m using it to authenticate to GitHub, and nobody browsing GitHub needs it.

Having them visible by default can be convenient. I’ve used it to populate authorized_hosts for example. However it is unnecessary and unexpected. If you use different private keys on each machine, it reveals a lot of opsec info you may not have expected to be public.

It’s a “public” key in the cryptographic sense, not in the address book sense.

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.

I disagree. The article points to simplifications that SSH did compared to GPG, like no web of trust.

But there's now something very close to one, a bit hidden though: SSHFP + DNSSEC

I think a lot of people here may not be familiar with SSHFP records, so check https://fanf.livejournal.com/130577.html for a more detailed explanation.

It's more or less a work around the problem of initially trusting a key, by using SSHFP records to verify that the server keys are validated by the domain, with DNSSEC validating the whole thing.

When you can match server keys to domains and user keys to github users, you are just one link away from having a global picture of the web of trust.

EDIT: and I wonder how feasible it would be to do just that with a sniff of the initial handshake

> because that’s the easiest to create a unique key for GitHub

And how many people do you think have done that, instead of uploading the keys of the servers/laptops/etc. they use?

I hate to say this, but Bitcoin did it right: by having a discardable private+public pair of keys derived from a seed key, it prevents leaks of information by correlation based on the public key.

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?

Equally they might use the same user name as on other services, thus making them traceable.

Ultimately if you care about privacy then it’s up to you, the individual, not to share that information or to provide anonymous information yourself.

Sharing identifiable information and then blaming the company you shared it with is like blaming the horse for bolting after you’ve intentionally left the barn door open. Sure it should be that way but ultimately it’s your own responsibility to keep your stuff safe.

I’d agree with your point more if you were advocating that documentation should be more explicit. Ie helping educate users into making smarter choices.

So your argument against SSH keys are just as valid for all the other items of meta data you’re dismissing as not a privacy problem.

And that’s the point I’m making. If you care enough about privacy that your public SSH key is an issue, then creating a GitHub account is not the brightest idea regardless of their policy on public SSH keys.

I don’t disagree that GitHub could do a better job documenting this risk nor that an ideal scenario would be giving users the option. But they’re all just side stepping the real issue that this is not a privacy because of the fact that public SSH keys are not more of a risk than any of the other data you’re already volunteering to be published by virtue of signing up to a social platform.

If you want privacy then host your own git server (it’s really easy!) because GitHub is designed around sharing, not privacy.

It’s weird the number of people here who don’t realise that convenience and privacy are often opposing forces and I bet the majority complaining don’t even pay for their GitHub account. Yet they are still complaining about specific aspects of privacy while willingly handing over a crap load more identifiable information for free. The whole debate here screams of security theatre: privacy for show rather than actual safeguarding of personally identifiable data.

The setup process looks a bit crazy, so I’m hoping it’s gotten easier since 2014? I would love to test it out, but life is too short for the process they’ve outlined...

You are correct.

> The setup process looks a bit crazy, so I’m hoping it’s gotten easier since 2014?

I don't think I used that in uni, so I can't tell you how complicated it was. It's just a nice didactic article that I found explained all the details.

In practice in 2021, you run a sshfp script on the server, and publish the output of the script on your DNS by adding a key.

If you use scripted DNS, it's a one step process, if not, a 2 step process.

> Since .guix-authorizations is a regular file under version control, granting or revoking commit authorization does not require special support. In the example above, commit B is an authorized commit by Alice that adds Bob’s key to .guix-authorizations. Revocation is similar: any authorized committer can remove entries from .guix-authorizations. Key rotation can be handled similarly: a committer can remove their former key and add their new key in a single commit, signed by the former key.

I'm unaware of the implementation details, such as whether git will validate sigs for a PGP key which has been revoked. That's a fair question, although for this usecase i can't imagine how it would be useful to deny signatures from the entire project's history because a key has been revoked.

  GIT_SSH_COMMAND="ssh -i ~/.ssh/id_ed25519_company_a -o IdentitiesOnly=yes" git clone ...

  git config core.sshCommand "ssh -i ~/.ssh/id_ed25519_company_a -o IdentitiesOnly=yes"

there is no security benefit from revoking individual keys unless they've been compromised - however, the likelihood of only leaking a single key is extremely unlikely.

There are very few attack vectors how you can compromise a private/public key pair and they all basically boil down to local access. This is not a PreSharedKey situation like a password, where both parties effectively share a single string for authentication. The private key never leaves the authenticating machine, as you're only sending a signature over which will be validated against the public key. So, how are you going to compromise a single key that splitting them increases your security?

you're either completely compromised and somebody has filesystem access or you've forwarded your SSH-Agent to a compromised host. When its the former, you'll have to have the private-key encrypted so they're unable to use them (encrypted at rest) and when its the later, you cannot have your keys added to the agent, making the forwarding redundant in the first place.

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.

These are not binary attributes. A public key absolutely can be a secret, and in many cases should be.

> If it was a public messaging service like HN, or public comments on Twitter or Facebook, then yes.

You're avoiding the question because in this case it isn't a "public messaging service." It's an attribute of an account configuration.

> Thus if privacy is a concern then you shouldn’t be using GitHub in the first place.

Nonsense. What if I use a private email for my github account? What if I only use private repositories?

You're repeatedly making an error of portraying privacy as black and white and it simply is not.

> I’m saying the SSH public keys are a lower risk than other details you share in GitHub.

No, you made a categorical, absolute statement that "If you need privacy then you shouldn’t be uploading to GitHub in the first place."

This statement is utter nonsense. Now you're just arguing that you didn't say what you actually said.

> That’s literally the point I’ve been making.

No, your statement that we're discussing was "If you need privacy then you shouldn’t be uploading to GitHub in the first place."

This statement is flatly incorrect. Your comments are demonstrably false, and your followups are irrelevant deflections.

I answered your question despite it being a straw man argument.

> No, you made a categorical, absolute statement that "If you need privacy then you shouldn’t be uploading to GitHub in the first place." This statement is utter nonsense.

Thus far all the arguments you’ve made have been either unsubstantiated or straw man.

Take the quote above, you argue it’s nonsense but offer zero evidence to back up that remark.

> Now you're just arguing that you didn't say what you actually said.

You’re changing the subject again instead of providing a counter argument. I’ve made my points clear, with examples as to why I’ve came to that conclusion, and there’s history of our chat in this forum.

This is clear an emotive topic for you but if you want to prove me wrong then please at least stick to the subject.

You didn't, and I think that's all that needs to be said. There's no need to address the rest of your comment. I don't care to engage in whatever it is you're doing.

http://www.paulgraham.com/disagree.html

Thus far we’ve seen DH2, DH3 and DH4 but you haven’t yet refuted my central argument (nor even anything close to it) despite posting a multitude of emotionally charged paragraphs.

Now take a look at the discussions I’ve had with others in this thread. They’ve been on topic and informative. Unlike the responses from yourself.

I’m genuinely open to discussion, if you’re genuinely interested in having one.

Take another look at your own responses, vis a vis that article. You and I are done here.

Pity you couldn’t be bothered to hold a proper discussion here because some of your other posts in other threads have been informative. C’est la vie

> If you need privacy then you shouldn’t be uploading to GitHub in the first place. The moment you do that you’re publishing email addresses, other projects that you contribute too and potentially leaking your timezone by virtue of commit times.

You are wrong. GitHub doesn't have to leak anything, apart from your public SSH key.