; .config/git/id_example
[user]
name = "git"
email = "git@localhost"
[core]
sshCommand = "ssh -i ~/.ssh/id_example"put this in your ~/.gitconfig-personal
[core]
sshCommand = "ssh -i ~/.ssh/github_personal_ed25519"
and this in your ~/.gitconfig-work [core]
sshCommand = "ssh -i ~/.ssh/github_work_ed25519"You can also set that in your `.git/config` file on a per repo basis. Additionally you can set `GIT_SSH_COMMAND="ssh -i /tmp/custom_key_ed25519 -o IdentitiesOnly=yes" git pull` to override whatever is in your global or repo config for 1 off pulls as a different user.
If you wanted to have it all in your git config, you could set core.sshCommand to "ssh -i ~/.ssh/id_rsa-client", maybe combined with includeIf as in the article (since it's a glob match, you could match on the github org name).
Main/default config (~/.gitconfig):
[user]
email = [email protected]
name = Victor Bjelkholm
[includeIf "gitdir:/home/user/projects/user-a/"]
path = /home/user/.gitconfig-user-a
[includeIf "gitdir:/home/user/projects/user-b/"]
path = /home/user/.gitconfig-user-b
Then in .gitconfig-user-{a,b}: [user]
name = UserA
email = [email protected]
[core]
sshCommand = ssh -i /home/user/.ssh/user_a_id_ed25519
Or, even more separation, create separate users/accounts on the computers you use. ; include only if a remote with the given URL exists (note
; that such a URL may be provided later in a file or in a
; file read after this file is read, as seen in this example)
[includeIf "hasconfig:remote.*.url:https://example.com/\*"]
path = foo.inc
[remote "origin"]
url = https://example.com/git*The reason for doing it by location is probably because my directory structure for projects look something like this:
/home/user/projects/organization/project
so github.com/victorb/neat-project would go into /home/user/projects/victor/neat-project
So my solution is tailored to that structure I suppose :)
At home (I mean a personal box I for personal project and some other public contributions), my directory structure is like:
~/sources/forge/organisation/project
where `sources` has the same meaning as your `/home/user/projects` ; and your example will end up here to ~/sources/github.com/victorb/neat-project
The structure used has some great influence on solution adopted I think :)But how could I also select the config for an initial clone of a repo based on the repository address?
Say my IdentityKey that I use for regular ssh is also associated with GH user foo, and then I have the above gitconfig to use a different key associated with GH user bar under certain directories. It's still possible that ssh will try the IdentityKey before the `-i` key when I do git operations under those directories, which means GH will identify me as user foo anyway.
I'm not sure what order ssh uses to sort the union, if any, but at least in my case it seems to always use the IdentityKey before the `-i` key even though it prints them in the opposite order initially (according to `-vvvv`).
And no, `-o IdentitiesOnly=yes` doesn't affect this behavior.
I'm curious, what are people's opinions about the pro/cons of maintaining multiple GitHub identities like this?
Personally, I have never found it necessary to do this, but about 1/3 to ½ of the people I work with usually have "-companyname" in their usernames, so it appears semi-popular.
What I do is just add my work email as a secondary to my GitHub account and configure the work laptop to use that email, and I generate a new RSA key and add it to my one account. Then I also set up the notifications to use that work email as the notification email for things in that organization
My "Pros" list for doing it this way:
* Simple to configure my git/ssh settings - just add the SSH key on my work laptop to my normal GitHub account
* Easy for someone to identify and even reach me if they were to see a commit in GitHub. For instance, if they know I wrote something they might want to hire me again later to update it.
* I "Sign in with GitHub" to things like developer tools (like Codesandbox, for instance), I get to easily keep control of that account even when I change jobs.
"Cons" I can think of:
* Technically a malicious actor in (or who has compromised) corporate IT could impersonate me by stealing my key from my work-owned computer, cloning my private Github repos, and could introduce changes into other repos I have access to. So I assume if I had high-level access to important OSS projects, this would be a danger for targeted hacking. (Obviously since I can remove the keys at the end of an engagement, I can at least limit my exposure to just current clients/employers.)
Is there anything else that makes you prefer to use a company-specific identity?
Ultimately, I think having work-specific accounts is preferable, and I wouldn't be surprised if a lot of IT departments also prefer this (however, this is also coming from the medical space, where controls are rather tight and security is extremely important and heavily audited)
The only thing that would need to change, AFAIK, is the name and email you use for commits, not necessarily our ssh key.
I do use this:
[includeIf "gitdir:~/Projects/Client1/"]
path = ~/Projects/Client1/.gitconfig
[includeIf "gitdir:~/Projects/Client2/"]
path = ~/Projects/Client2/.gitconfig
to define the user.name and user.email for different projectsTypically, for Client1 and Client2, both clients could invite the same account to the organization.
ssh config:
Host github.com gist.github.com
Hostname %h
User git
RequestTTY no
RemoteCommand none
IdentitiesOnly yes
ControlMaster no
Match host github.com,gist.github.com exec "~/Developer/C++/getargv/getargv -0 -s 1 $PPID | env POSIXLY_CORRECT=1 xargs -0 getopt '46AaCfGgKkMNnqsTtVvXxYyB:b:c:D:E:e:F:I:i:J:L:l:m:O:o:p:Q:R:S:W:w:' | perl -pe 's|.*? -- ||' | fgrep -e username1"
IdentityFile ~/.ssh/keys/github_rsa
Match host github.com,gist.github.com exec "~/Developer/C++/getargv/getargv -0 -s 1 $PPID | env POSIXLY_CORRECT=1 xargs -0 getopt '46AaCfGgKkMNnqsTtVvXxYyB:b:c:D:E:e:F:I:i:J:L:l:m:O:o:p:Q:R:S:W:w:' | perl -pe 's|.*? -- ||' | fgrep -e username2"
IdentityFile ~/.ssh/keys/github_rsa2
I set the common github configs in the top Host block, then each Match block looks at the arguments passed to ssh, parses them, and checks for the github username and if it matches, sets the correct key.The ~/Developer/C++/getargv/getargv program is just an implementation of `cat /proc/$PPID/cmdline` for macOS, on linux you don't need a separate tool.
This works for cloning, pushing, pulling, etc.
It was very odd. Either (a) the person responding to me was uninformed, or (b) that's actually Github's policy and it's not nearly as prominently displayed as it should be.
The third bullet point at https://docs.github.com/en/site-policy/github-terms/github-t... --
> One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine).
This is the primary reason why I have only ever used my own personal account for work stored at GitHub. If a company is expecting its employees to use a separate work GH account, one assumes that company is planning to pay for all those accounts for its employees.
There have also been times when I would like to have access to a second GitHub account for testing purposes. (In particular, for testing GH behaviour when the accounts corresponding to PR commits, PR creator, and PR merger all differ -- see for example <https://github.com/isaacs/github/issues/1368>.)
I imagine some large number of folks that have two accounts are Pro on at at least one of them, if not both.
> One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine).
https://docs.github.com/en/site-policy/github-terms/github-t...
I suppose you could pay for additional accounts though.
Anyways, I would use SSH host aliases for this myself as well. Might want to consider `IdentitiesOnly yes` as well.
"if you choose to control a machine account as well, that's fine, but it can only be used for running a machine"
I'm not aware that "running a machine" has a legal definition. I think it's fine, if you have a corporate account and a private email you are probably fine. I think they mainly have that as some sort of rate limiting legalese, to prevent abuse from "account hopping" i.e. abusing the github api or spamming, etc..
If your work account is a "legal entity", i.e. it is a person under corporate personhood laws, this definition also doesn't really hold water (both you and the corporation account count as legal persons, so this doesn't do much, other than the cost of an incorporation being non-zero). Just don't do weird things with your separate accounts, and actually keep them separate, and you're probably fine.
Yubikey's have a limited number of slots for GPG keys by the way... I'm curious to know how you stuffed as many subkeys as you want into the single AUT subkey slot (or even stuffed subkeys usable for authentication into all 4 of the slots it gives you)...
I'm the author.
Perhaps not the answer you're expecting (mentioning this anyways, because perhaps it'll be useful/interesting to some folks), but I just ended up paying for GitKraken and suddenly managing multiple accounts (not just GitHub, but also my self-hosted Gitea instance and other servers) became as easy as choosing a different value in a dropdown: https://www.gitkraken.com/blog/managing-mulitple-github-acco...
Paying for something like a Git client felt silly, but at the same time it's good, does what I need and runs on every playform that I use, while also not annoying me too much, same as with JetBrains IDEs and something like MobaXTerm. Before that I used SourceTree and Git Cola because some operations are more convenient with a GUI instead of a CLI, though they didn't have that functionality.