To shortcut a lot of this developing twister of why people should use different keypairs for different ssh hosts:
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.)
> 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.
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.
I am not sure actually because I do not have any persistent github accounts. I only do them in a throwaway fashion. (Of course Github is making that more annoying by the month, as every other bigcorp site.)
GitHub does require that SSH keys only be used by a single user 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.
> and it was a hassle to get local repositories to use the correct keypair
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
And then instead of
git clone git@github.com:companya/foo.git
I'd type
git clone gh-company-a:companya/foo.git
Likewise, instead of
git clone git@github.com:acmeinc/baz.git
I do
git clone gh-acme-com:acmeinc/baz.git
and so on.
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.
Doesn't OpenSSH by default also send all your public keys to the server to see if it accepts any of them? That would allow the server operator to identify you if you aren't careful.
Can be configured in .ssh/config.
Shortcut for that is to use subdirs or filenames for keys that arent searched automatically and not have a default-name-key.
>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.
How to practically manage this, with git in particular.
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.
Or keep sensitive identities in a different location, so they aren't automatically picked up like that. That forces you to specify an identity file when you need one of those, but that small inconvenience is probably not a concern if the identity is that sensitive.
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.)