Being a developer today most likely means you have one or more accounts at different Git service providers, like: GitHub, Bitbucket, GitLab or Microsoft Azure DevOps. Personally, I have an account at several of these providers. And I'm also working as a contractor where, I sometimes have clients that doesn't allow personal accounts to be invited, but instead requires that a specific corporate account is created. When it comes to authentication, I'm using SSH-keys. I have multiple keys in play, both depending on account and from what machine the key is used. In this post, I'll be showing ONE way of setting up an environment that meets the requirements: be able to have multiple users in .gitconfig and to have multiple SSH-keys working smoothly from the same machine against a specific Git service provider, using different organizations.
Different .gitconfig settings
Lets pretend we have the following sample:
With this in mind, I want to have a baseline of
.gitconfig settings (used in "OpenSourceRepos" and then have one configuration for "FooCompanyRepos" and one for "BarCompanyRepos":
- C:\OpenSourceRepos ->
- C:\FooCompanyRepos ->
- C:\BarCompanyRepos ->
Contains my normal stuff (hooked in difftool, mergetool, etc) and two additional directives that includes additional
[includeIf "gitdir:C:/FooComanyRepos/"] path = .gitconfig-foocompany [includeIf "gitdir:C:/BarComanyRepos/"] path = .gitconfig-barcompany
.gitconfig-foocompany & .gitconfig-barcompany
.gitconfig I've created two new files:
.gitconfig-barcompany; in which I now can have additional settings for that company, e.g:
[user] name = Daniel Wertheim email = firstname.lastname@example.org
[user] name = Daniel Wertheim email = email@example.com
Now lets deal with having multiple SSH-keys.
Step 1 - generate some SSH-keys
Lets generate two SSH-keys, one that will be used for "foocompany" and one for "barcompany" (warning, ensure you don't destroy any existing keys):
$ ssh-keygen -t rsa -b 4096 -C "firstname.lastname@example.org" Generating public/private rsa key pair. Enter file in which to save the key (/c/Users/muppet/.ssh/id_rsa): /c/Users/muppet/.ssh/id_rsa_foocompany Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /c/Users/muppet/.ssh/id_rsa_foocompany. Your public key has been saved in /c/Users/muppet/.ssh/id_rsa_foocompany.pub.
$ ssh-keygen -t rsa -b 4096 -C "email@example.com" Generating public/private rsa key pair. Enter file in which to save the key (/c/Users/muppet/.ssh/id_rsa): /c/Users/muppet/.ssh/id_rsa_barcompany Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /c/Users/muppet/.ssh/id_rsa_barcompany. Your public key has been saved in /c/Users/muppet/.ssh/id_rsa_barcompany.pub.
For this guide, I will asume we are using Azure DevOps as a Git service provider. Lets pretend I have access to two different organizations there:
I've logged in and uploaded my newly generated public SSH-keys
Now, if we go to a repo, e.g.
"https://dev.azure.com/foocompany/_git/sample" and use the value suggested for e.g. cloing the repo:
git clone firstname.lastname@example.org:v3/foocompany/sample/sample
It will try and use a default SSH-key located under the user's
.ssh folder, e.g:
/c/Users/muppet/.ssh/id_rsa. But what I want is my
id_rsa_foocompany SSH-key. How can we configure this?
Step 2 - ./SSH/config
To associate what SSH-key to use against what external Git-repo, we will create a new file
config (no file-extension) in:
$ touch config
Host foocompany-azure HostName vs-ssh.visualstudio.com User git IdentityFile /c/Users/muppet/.ssh/id_rsa_foocompany IdentitiesOnly yes Host barcompany-azure HostName vs-ssh.visualstudio.com User git IdentityFile /c/Users/muppet/.ssh/id_rsa_barcompany IdentitiesOnly yes
After restarting the bash-console, I can now use the following URL for the previous repo:
$ git clone git@foocompany-azure:v3/foocompany/sample/sample Cloning into 'sample'... Enter passphrase for key '/c/Users/muppet/.ssh/id_rsa_foocompany':
And that's it. We now get prompted for credentials (given you generated the key with a passphrase) for the correct SSH-key.
Again, this was one way to solve my requirements. Use if you want to. Or not. Share better solutions via comments.