Here’s the situation:
- The easiest and most secure way to interact with Git repos hosted on GitLab is over the SSH protocol.
- While most people only use one GitLab.com account, a freelancer or consultant might need to work with repos from multiple accounts.
If that freelancer attempts to upload their public SSH key to multiple accounts, they’ll get the following error message from GitLab:
Fingerprint has already been taken.
Assuming they don’t want to use password-based authentication over HTTPS as a workaround, how can our friendly freelancer get SSH working?
Workaround: One SSH key pair per GitLab.com account
The solution is to use a different SSH key pair with each GitLab.com account. How do you do it?
- Generate a new SSH key pair. (Detailed instructions).
- Add the SSH key to your GitLab account. (Detailed instructions).
How will SSH know which key to use for a given repo? Since Git 2.10, you can use Git’s
core.sshCommand option to configure how Git invokes the
ssh command. As with all Git options, you can set it globally, or per repository. Let’s set it to point SSH at the key we just created.
- Open a terminal and make sure you’re in the repository that needs configuring.
git config core.sshCommand "ssh -i ~/.ssh/id_MY_KEY_NAME_HERE -F /dev/null"
-i tells ssh which “identity” file to use for this command.
Now try running
git pull. You should be prompted for the private key’s password and the pull should finish successfully. You did it!
Configuring SSH agent to use the new key
If you weren’t prompted for the password and the
git pull operation failed, you’re probably using an SSH agent. The agent likely tried to use your default SSH key and it didn’t fit the lock. That default identity is usually “id_rsa”.
Fortunately, the solution is simple: Tell SSH Agent about your new key using
ssh-add. For example, if your new key is called
id_yellowbanana and it’s stored in
~/.ssh, the command would like like this:
If you’re on Windows and it doesn’t know where
~ is, try this instead from PowerShell:
Next, list the keys your agent is managing with
ssh-add -l and see if the new key is listed. It should be there.
git pull again. If your agent is configured property, you should be in business.😎
Chicken and egg scenario: git clone
If you’re cloning a real live chicken, you don’t have a chicken and egg scenario. If you’re cloning a GitLab repo over SSH and you want to use an alternate identity, you do.
Jokes aside, what if you haven’t even cloned the repo yet? How do you tell Git which SSH identity to use?
You can temporarily set the
GIT_SSH_COMMAND environment variable.
GIT_SSH_COMMAND='ssh -i ~/.ssh/id_yellowbanana' git clone firstname.lastname@example.org:myuser/somerepo.git
$env:GIT_SSH_COMMAND='ssh -i ~/.ssh/id_yellowbanana' git clone email@example.com:myuser/somerepo.git
core.sshCommand on the repo like we did earlier.
That was easy! Now you still have the convenience and security of SSH, and you’ve got it across all your GitLab accounts.