[Gargyle]

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

[giaour]

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

[Gargyle]

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

[giaour]

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.

[codetrotter]

> 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 [e-mail]:companya/foo.git

I'd type

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

Likewise, instead of

    git clone [e-mail]: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.

[WesolyKubeczek]

I guess you also need

   IdentitiesOnly yes

in there.

Otherwise all your public keys will be tried regardless.

[drothlis]

Another way is to set $GIT_SSH_COMMAND when cloning:

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

and then set it in your checkout's .git/config for subsequent fetches & pushes:

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

[Gargyle]

Right. They always use git@ instead of account@ and there is no further meta in the git remote url. (gut remote url is a funny typo)

[newaccount74]

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.

[Gargyle]

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.

[jonnycomputer]

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

[fstelzer]

You can configure which key to use when signing your work https://git-scm.com/docs/git-config#Documentation/git-config...

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.

[jonnycomputer]

Ah, this is what I was looking for. Thank you.

[hirundo]

Generate a different public key for each service. Don't use the one for github, etc., anywhere else.

[newaccount74]

OpenSSH by default tries authenticating with all your identities. You should probably turn that off too.

[dspillett]

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.