Use SSH with multiple GitLab.com accounts

3 minute read Published:

Working with your Git repo over SSH is convenient and secure. Here's the trick to using SSH with multiple GitLab.com accounts.

Here’s the situation:

  1. The easiest and most secure way to interact with Git repos hosted on GitLab is over the SSH protocol.
  2. 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?

  1. Generate a new SSH key pair. (Detailed instructions).
  2. 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.

  1. Open a terminal and make sure you’re in the repository that needs configuring.
  2. Run git config core.sshCommand "ssh -i ~/.ssh/id_MY_KEY_NAME_HERE -F /dev/null"

The -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:

Bash:

ssh-add ~/.ssh/id_yellowbanana

PowerShell:

If you’re on Windows and it doesn’t know where ~ is, try this instead from PowerShell:

ssh-add $env:UserProfile/.ssh/id_yellowbanana

Next, list the keys your agent is managing with ssh-add -l and see if the new key is listed. It should be there.

Try running 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.

Bash:

GIT_SSH_COMMAND='ssh -i ~/.ssh/id_yellowbanana'
git clone git@gitlab.com:myuser/somerepo.git

PowerShell:

$env:GIT_SSH_COMMAND='ssh -i ~/.ssh/id_yellowbanana'
git clone git@gitlab.com:myuser/somerepo.git

Then configure 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.