Host github-client1
Hostname github.com
User git
IdentityFile ~/.ssh/id_rsa-client1
Host github-client2
Hostname github.com
User git
IdentityFile ~/.ssh/id_rsa-client2
Main/default config (~/.gitconfig):
[user]
email = git@victor.earth
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
[user]
name = UserA
email = UserA@DomainA.local
[core]
sshCommand = ssh -i /home/user/.ssh/user_a_id_ed25519
; 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*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.
put this in your ~/.gitconfig-personal
[core]
sshCommand = "ssh -i ~/.ssh/github_personal_ed25519"
[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 / clones as a different user.
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/bin/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/bin/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 company2"
IdentityFile ~/.ssh/keys/github_rsa2
The ~/Developer/C/getargv/bin/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.
> 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.
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)
Also, once you leave that company, you don't have to worry about unsubscribing from that company's repos, issue threads, etc, or worry about people still @-mentioning you because you participated in those repos before.
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
; .config/git/id_example
[user]
name = "git"
email = "git@localhost"
[core]
sshCommand = "ssh -i ~/.ssh/id_example"
git config --global alias.as-example '!git -c include.path=~/.config/git/id_example'
git as-example commit -m "my commit message as example"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.
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)...
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).
I'm the author.
[user]
name = "My Name"
useConfigOnly = true
[alias]
whoami = "!f() { echo $(git config --get user.name)' <'$(git config --get user.email)'>'; }; f"
So if you type "gitdir:~/work" instead of "gitdir:~/work/", you will lose some time wondering why your configuration is ignored.
[1]: https://git-scm.com/docs/git-config#_conditional_includes
One can set a password on the ssh key, but I still felt a bit paranoid about it. I found a way out with fine-grained personal access tokens which allow you to choose the repositories this token will have access to [1].
My setup consists of two ingredients:
1. GPG encrypted fine-grained PAT: `gpg -c --no-symkey-cache --pinentry-mode loopback my_name` ends up into `my_name.gpg` secret.
2. A git credential configuration which is generic across git repositories:
[credential "https://oauth2@github.com"]
helper = "!f() { test \"$1\" = get && echo \"password=$(gpg -d --pinentry-mode loopback --no-symkey-cache $_GITHUB_TOKEN)\"; }; f"
And it only activates for git urls of the from "oauth2@github.com" which allows you to clone public repos without questions.
Another advantage is that you can share the same repo with other people, no need to maintain a copy.
Disadvantage is that you have to enter password each time you push/pull.
[1] https://github.blog/2022-10-18-introducing-fine-grained-pers...
Run ssh-add in your terminal session before doing your push/pull dance — this way you only have to enter the password once. This gives you the security of the password protected key without bothering you too much in practise.
If you need to pull on a remote that doesn't have your private keys (as is good and proper) you can run ssh -A foo@bar.com to take that identity with you onto that remote (e.g. so you are able to pus/pull from there).
> Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent. A safer alternative may be to use a jump host (see -J).
> Run ssh-add in your terminal session before doing your push/pull dance
originally my comment was about gpg encrypted files. also I suspect any kind of agent would expose privileges of my key to others if they have sudo.
Doesn't the article fix exactly that?
if I understood correctly, the article suggests the way how to choose ssh key among those already stored on the server
I'm speaking about a situation when the space is shared. Basically every co-worker can ssh into machine and then do `sudo su` into a shared user, under which some R&D script is running and being fixed/adapted once for a while.
For scientific projects it may also be convenient, having a jupyter notebook running under tmux of the same account. Then collaborative (but not concurrent) work is possible on the project.
I use Starship (https://starship.rs) to manage my prompt, and wrote a short script that only runs if I'm somewhere in a git repo, and if so finds my Git user's email and looks up the corresponding letter in an associative array declared in my ~/.config/starship-zsh/.zshenv:
git_email=$(git config --get user.email | perl -pe 'chomp if eof')
letter=$STARSHIP_GIT_USERS[$git_email]
echo -n $letter
[custom.git_user]
command = "ZDOTDIR=~/.config/starship-zsh /path/to/the-script-above.sh" # set ZDOTDIR, makes zsh load the .zshenv file
when = "git rev-parse --git-dir >/dev/null 2>/dev/null" # only run if we're in a git repo
format = ' $output'
i mean if remote is https github com slash dzmitry lahoda slash web3.nix
than local is /home/dz/github com slash dzmitry lahoda slash web3.nix
navigation is easy. forks easy. no project1 or client 1. just navigation overlay. same works for consumption of knowledge and learning.
one may do codespace with nix easy too or many local homes.
nix and path overlays is superior and easy to maintain.
nix makes remote, local, ci, codespace, user switch, depending on dlmany versions of same repo super easy.
even by unix idiots like me.
that not full schema so. there are tags and data properties (security, size, files count, uniquiness of copy).
so decide if store local or remo only, git and syncthing same time, torrent and syncthing, gdrive and git, keepass and syncthing, what devices, ipfs. any combo.
tags when overlays (forced hierarchy fail). when git forks, than many remotes with overlay following most active fork.
that approach partially fixes some of my mental issue i guess. oh, i want to install zfs to fix duplication.
hardware keys for security i use also. thesd days can mix same key, but held ssh, crypto, aws creds on same device.
Does this happen in practice? Most commits on professional git repos that I work on are of the form <username>@users.noreply.github.com.
GitHub took it upon themselves to change email addresses and author names when merging via the UI buttons like "Squash and Merge" in 2018 and then again in 2019. See <https://github.com/isaacs/github/issues/1368> for the tedious details.
Essentially the post-2019 behaviour seems to be that where possible with "Squash and Merge" they will set noreply@github as the committer so that they can sign the merged commit themselves, and set author name & email to what they have recorded for the GH account involved (and the signature is then a record that GH have verified that account's involvement).
Personally I think it is shocking that they ignore the name and email address that the actual author of the commit has selected. This is both a violation of the author's intentions -- for example, you may set work and personal email addresses in different repositories as discussed here, but GitHub will rewrite them all to the same thing when other people press "Squash and Merge" on your pull requests -- and potentially a doxxing security risk.
I have considered re-reporting this to GitHub via the newer community discussions or via support again, but given the extent to which they've ignored all such reports over the last five years it is hard to find the motivation to do so.
The project might not look active, but that's because it just works. 12 years old now.
I have a github.com folder with all the repos I cloned from GH but I always have to type git config user.name/email before committing. It's so annoying at this point.
i've been using direnv to set env vars, but i'll probably switch to the conditional include.