So, any git repo cloned with the ssh identity defined under `gh-work` will take on the config of `gh-work.inc`, which includes the git identity, and also the same signing key as in the ssh config.
Essentially, the name `gh-work` becomes the distinguishing element in both my ssh identity and my git identity, and I find this easier to think about.
Just keep a .gitconfig in your HOME with aliases for your identities. Then just after initializing/cloning the repo do git config-company or git config-personal
I've been using `includeIf` with directory for ages (https://www.bobek.cz/til/git-identities/), the `hasconfig:remote` is really neat. And it also works when cloning the repository.
The includeIf stuff is pretty neat. I currently keep the SSH complexity in ~/.ssh, where I have several includes, one for each customer|project|identity. Things without unique hostnames, like github, get an alias assigned:
Host customer-github
Hostname github.com
IdentityFile ~/.ssh/customer_rsa
User git
All I have to do is use the alias in any git clone command and I'm done.
So glad I clicked on this link. I was already doing the `includeIf: "gitdir"` thing to separate work and personal stuff, but `hasconfig:remote` is a total game-changer.
Your key cannot be tied to more than one identity, and if you use GitHub Enterprise, your work identity may be restricted from contributing to repos outside of the Enterprise. This is to prevent cloning private code into public spaces. For this reason, you need to have separate keys.
If both of your keys are on the same computer they would most likely be compromised simultaneously, or not at all.
However if you're worried about this then you should probably be using a hardware token anyway - something that supports SSH authentication via FIDO2, GPG, or smart card interface.
I use a unique account with every distinct git org / github org that I interact with.
Even if I'm in my work profile and I need to do something in an org called `acmecorp`, I will create @acmecorp-identifier to do that.
This is just a very long experience...
* Security policies for work things have a blast radius of just that employer
* OSS things have a lifetime beyond the life of an employment / contract
* Source control elsewhere (GitHub / GitLab / Bitbucket / Gitea / Forgejo / etc) all has a local blast radius, and if a provider / org forces changes (roll your keys!) then the impact is limited to just that provider
* When something changes ownership (i.e. an org), the impact to me is low
It seems much more sane.
I think of a single git identity across multiple orgs as a bit of a smell.
I use different accounts for my work GitHub and my personal GitHub, so this approach would be great if I shared a machine for both of them to keep separation.
I use `insteadOf` instead of ssh alias because my workplace use GitLab orgs. So instead of typing the full URL like:
git clone gitlab.com/acme-corp/project-name
I could use:
git clone work:project-name
But this kinda broke `includeIf` since it store the `insteadOf` remote url directly. I then had to convert existing repositories to use the `insteadOf` url.
This post is a great reference of what’s possible with git config wrt includes/remotes, and I’m sure I’ll be getting back to it.
One thing though: what’s the point of using separate keys for work/personal/github/gitlab? I fail to see a practical and security advantage over using one key (per workstation).
To add to my other replies to replies in this thread…
These days I prefer to use local VMs to compartmentalize different areas of work (personal, consulting, etc) so my git config is plain and simple. Lately I’ve been doing mostly consulting work around open-source so I’ve been using my primary GH account for the most part, but separate VMs allow me to use a different key (account) without advanced git config incantations.
As cool as this is, how many peoples' employers allow them to do either personal work from the work computers, or work work from their personal computers? My company is quite strict on both.
For many of the companies that I've worked at, the laptops were taken home to be used as personal computers at the end of the day and this was a well-known thing and I was often looked at weird when I said I had another laptop.
One time I took the wrong laptop in and had to work on my personal laptop in the office. It wasn't so much fun that day.
I love that Rek drew the image on your about page. I knew I recognized their work as soon as I saw it.
I do something similar, but instead of `insteadOf`, I just clone the repo with `gh-work:org/repo`, and in the git config:
So, any git repo cloned with the ssh identity defined under `gh-work` will take on the config of `gh-work.inc`, which includes the git identity, and also the same signing key as in the ssh config.Essentially, the name `gh-work` becomes the distinguishing element in both my ssh identity and my git identity, and I find this easier to think about.
One even-better approach IMHO
Just keep a .gitconfig in your HOME with aliases for your identities. Then just after initializing/cloning the repo do git config-company or git config-personal
you don't have to mess with ~/.ssh/config
Just put this in your ~/.gitconfig (or ~/.config/git/personal as in the article)
This makes submodules easy without the `insteadOf`And if you have more than one SSH identity?
You can also put that in your includeIf confs. I updated the parent comment
Sounds like a different problem.
I've been using `includeIf` with directory for ages (https://www.bobek.cz/til/git-identities/), the `hasconfig:remote` is really neat. And it also works when cloning the repository.
Thank you for this! I have exactly the same problem and was waiting for the solution to present itself, which it now has.
Aside: I use NixOS with home-manager (on linux and mac), which makes this trivial [1]. Added the following lines to my home-manager config:
[1]: https://nix-community.github.io/home-manager/options.xhtml#o...The includeIf stuff is pretty neat. I currently keep the SSH complexity in ~/.ssh, where I have several includes, one for each customer|project|identity. Things without unique hostnames, like github, get an alias assigned:
All I have to do is use the alias in any git clone command and I'm done.I have created a tool 12 years ago (still actively maintained) to manage multiple GitHub SSH identities:
https://github.com/dolmen/github-keygen
So glad I clicked on this link. I was already doing the `includeIf: "gitdir"` thing to separate work and personal stuff, but `hasconfig:remote` is a total game-changer.
absoluelty! I can't believe this treasure was hidden as a draft for three years!
This is a nice trick. But if you:
* use a dedicated work machine and
* also want to version control your dotfiles (including ~/.config/git/) and
* don't want to leak your work repository organisation via your dotfiles,
you can instead add something like
which will override any settings above it and also fail gracefully/silently if work.gitconfig does not exist.> Note: I've had this post drafted for 3 YEARS!!! It's finally time to publish it.
I suddenly felt a deep connection with the author. It is not only me.
I promise you, my dear drafts, that one day, I will set you free to see the world!
Shameless plug for a tool I developed in order to easily switch git identities based on projects: https://github.com/cquintana92/git-switch-user
After configuring the identities you just need to run
And all the identity configuration (email, name, SSH key and optionally PGP key) will be set up into the repo's .git/config file.Saved me a ton of time.
Shameless plug for a tool I developed in order to easily manage GitHub identities for Git access via SSH:
https://github.com/dolmen/github-keygen
12 years old, but still actively maintained.
I hated configuring multiple Hosts/aliases in my ~/.ssh/config for Github/Bitbucket when dealing with different keys for different clients.
I ended up creating a "SSH environment" manager 4 years ago to help with this: https://github.com/theonejb/sshenv
It's worked wonderfully for me since then, and it's something I use almost daily.
Is there a risk with not using different keys for work and personal?
The private bits are all in the same place: if one is compromised, so are the rest.
There is also a risk using the same machine for work and personal. I’d address that first.
About signing keys, it would make sense stopping using a signing key (marking it as such and deleting it) once you stop a job.
Your signing key for personal projects probably has a different temporality.
> About signing keys, it would make sense stopping using a signing key (marking it as such and deleting it) once you stop a job.
What does this achieve exactly?
Your key cannot be tied to more than one identity, and if you use GitHub Enterprise, your work identity may be restricted from contributing to repos outside of the Enterprise. This is to prevent cloning private code into public spaces. For this reason, you need to have separate keys.
Interesting!
Curious though that the compliance rules are strict enough it warrants distinct keypairs, but not that strict for the devs to use dedicated hardware.
If both of your keys are on the same computer they would most likely be compromised simultaneously, or not at all.
However if you're worried about this then you should probably be using a hardware token anyway - something that supports SSH authentication via FIDO2, GPG, or smart card interface.
Why have multiple git identities in the same machine? I use a single different key with each machine and that's it.
I use a unique account with every distinct git org / github org that I interact with.
Even if I'm in my work profile and I need to do something in an org called `acmecorp`, I will create @acmecorp-identifier to do that.
This is just a very long experience...
* Security policies for work things have a blast radius of just that employer
* OSS things have a lifetime beyond the life of an employment / contract
* Source control elsewhere (GitHub / GitLab / Bitbucket / Gitea / Forgejo / etc) all has a local blast radius, and if a provider / org forces changes (roll your keys!) then the impact is limited to just that provider
* When something changes ownership (i.e. an org), the impact to me is low
It seems much more sane.
I think of a single git identity across multiple orgs as a bit of a smell.
I use different accounts for my work GitHub and my personal GitHub, so this approach would be great if I shared a machine for both of them to keep separation.
I use `insteadOf` instead of ssh alias because my workplace use GitLab orgs. So instead of typing the full URL like:
I could use: But this kinda broke `includeIf` since it store the `insteadOf` remote url directly. I then had to convert existing repositories to use the `insteadOf` url.I wrote a little bit about it here: https://bentinata.com/log/git-insteadof-includeif
This post is a great reference of what’s possible with git config wrt includes/remotes, and I’m sure I’ll be getting back to it.
One thing though: what’s the point of using separate keys for work/personal/github/gitlab? I fail to see a practical and security advantage over using one key (per workstation).
To add to my other replies to replies in this thread…
These days I prefer to use local VMs to compartmentalize different areas of work (personal, consulting, etc) so my git config is plain and simple. Lately I’ve been doing mostly consulting work around open-source so I’ve been using my primary GH account for the most part, but separate VMs allow me to use a different key (account) without advanced git config incantations.
Privacy for sure. It's no ones business to know how certain accounts are related.
Ah, right. E.g. using separate GH accounts for personal and work. Forgot about that!
GitHub does not allow you to share a key with another GitHub account anymore
Of course! I’ve been using separate GH accounts for work and personal stuff in the past myself. It’s been years since then and I completely forgot.
In fact, I was one of not too many who used separate account for work, and people didn’t understand it, wondering why the hassle.
They never did. The account is identified by the key, so it's impossible.
As cool as this is, how many peoples' employers allow them to do either personal work from the work computers, or work work from their personal computers? My company is quite strict on both.
I've not had a single employer care.
For many of the companies that I've worked at, the laptops were taken home to be used as personal computers at the end of the day and this was a well-known thing and I was often looked at weird when I said I had another laptop.
One time I took the wrong laptop in and had to work on my personal laptop in the office. It wasn't so much fun that day.
user.useconfigonly=true can also help
I really liked the website, the layout, typography, icons etc. Really well done!
Especially the TLD
The whole domain name for me, my childhood dog was named Benji :)
... time to go change my security questions