21–30 of 92 posts
that conditional include is nice, didn't know about that. i've been using direnv to set env vars, but i'll probably switch to the conditional include.
How do people handle multiple git identities with github+ssh? Since you always log in as the `git` user, you can't reuse keys. I end up with an ~/.ssh/config like: 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 Then clone using `git clone git@github-client1:username/repo.git` Is there a better way?
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?
And here I am modifying each .git/config by hand like a pleb
Earlier quoted context omitted.
Different gitconfigs per path on disk, git automatically uses the right identity depending on where you are on disk. Allows you to separate all projects into different users and every repository within those directories will use the specified user. Main/default config (~/.gitconfig): [user] email = git@victor.earth name = Victor Bjelkholm [includeIf "gitdir:/home/user/projects/user-a/"] path = /home/user/.gitconfig-u…
Does it work with subdirectories?
How do people handle multiple git identities with github+ssh? Since you always log in as the `git` user, you can't reuse keys. I end up with an ~/.ssh/config like: 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 Then clone using `git clone git@github-client1:username/repo.git` Is there a better way?
This is pretty cool. 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 t…
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)
How do people handle multiple git identities with github+ssh? Since you always log in as the `git` user, you can't reuse keys. I end up with an ~/.ssh/config like: 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 Then clone using `git clone git@github-client1:username/repo.git` Is there a better way?
How do people handle multiple git identities with github+ssh? Since you always log in as the `git` user, you can't reuse keys. I end up with an ~/.ssh/config like: 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 Then clone using `git clone git@github-client1:username/repo.git` Is there a better way?
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...
I find one disadvantage of SSH key auth, in case of GitHub in particular, that SSH key grants access to all the repos independently on the organization, etc, which becomes a bigger problem when sharing the machine with other people. 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…
Doesn't the article fix exactly that?
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