0

Multiple SSH Keys for multiple Bitbucket accounts

There are a few ways to achieve the holy grail of multiple bitbucket accounts linked to the same pc whilst never having to use a password, depending on what you put into your config file (more on that shortly) with a little doctoring of the odd link here or there you can negotiate multiple accounts on multiple repos with ease. This uses the bash prompt as if you’re using git it’s very likely you’ll have access to it

 

Let’s Go

I’ll assume that you’ve no SSH keys currently set up for bitbucket although the process for adding a new key/account to a system that already has one should be evident from the steps we go through here.

  • Navigate to the .ssh folder with the following command:
    • cd ~/.ssh
  • Create an ssh key for each account that you’d like to use, I’d also suggest setting a comment and the filename as something recognisably related to the account that you’d like to associate it with, a username is a great choice for both:
    • ssh-keygen -t rsa -C "user1" -f "user1"
  • for each one ensure that you’ve added your private keys to the RSA agent with the following:
    • eval $(ssh-agent)
    • ssh-add ~/.ssh/user1
  • Add the relevant public keys to the relevant accounts, for bitbucket it’s a case of:
    • logging in
    • clicking on your user icon at the lower left of the screen,
    • selecting Bitbucket settings > SSH Keys > add
    • open the Public ssh file and copy the contents into the window provided by bitbucket
    • Name it, save it and you’re done here

So far so normal, if we’d followed this process for just one ssh key and one account this would be exactly the way that you’d set yourself up. As we’re looking to be able to negotiate with two different accounts we’ll need to make sure that we’ve registered both keys. We’ll also need some way to tell our computers when to use which key and this is where the config file comes into play.

config file

In your ~/.ssh/ folder create a file called config and put the following into it:

# Account for user1
Host user1.bitbucket.org
   HostName bitbucket.org
   IdentityFile ~/.ssh/user1
# Account for user2
Host user2.bitbucket.org
   HostName bitbucket.org
   IdentityFile ~/.ssh/user2

So in the above we’ve done a few things, we’ve set a default key to be used for bitbucket, in this instance it’s a file called id_rsa and it what would be created if no filename were specified on creation. After that we’ve set up some details outlining which keys you’d like to be used for which hosts – so far so good!.

Now to use the different keys you’ll have to make a slight change to your repos and/or clone links.

Clone links:

A standard ssh clone link would look something like this:

git clone git@bitbucket.org:WorkTeam/Projectname.git

but this now doesn’t resolve to either of the hosts in the config file we just made, if we put our username and a full stop immediately after the @ and before the bitbucket.org we’ll be left with:

git clone git@user1.bitbucket.org:WorkTeam/Projectname.git

and this references the host listed above for user1 and will use the referenced rsa key.

Amend Repos:

For repos that you’ve already cloned you’ll need to tell git to use a different upstream link to take your new host details into account, to take a look at your current links use the following command:

  • git remote -v

As you can see from the response you’ll have something like this:

$ git remote -v
origin  git@bitbucket.org:WorkTeam/Projectname.git (fetch)
origin  git@bitbucket.org:WorkTeam/Projectname.git (push)

To change it simply use the command:

$ git remote set-url origin git@user1.bitbucket.org:WorkRepo/Projectname.git

And you should now be able to push and pull to your heart’s content, just remember to amend yourssh clone link each time you clone a new repo otherwise bitbucket will kick you out!

Extra credit:

So the above method is something that I’ve found to work and it’s served me well for a while, until I tried cloning a project containing a submodule (wonderful things, I’ll write an article on them soon) using the commands ‘git submodule init’ and ‘git submodule update’. Both of these commands make use of the file ‘.gitmodules’ which I found to be filled in the following way:

[submodule "SysLib"]
path = SysLib
url = ssh://user2@bitbucket.org/myaccount/Projectname.git

I did see methodologies which used this kind of syntax whilst I was looking around for how to do this in the first instance but I didn’t want to have to restart the process to make sure that I could use a fringe feature… To the config file!

By adding another entry into the config file we can make sure that the correct ssh key is used when we’re using our ‘username’ as well as when changing the host section of the entry as we have been above. I also decided that I didn’t want to have to amend my links for both accounts so I set the host to be just bitbucket and my user1 account is effectively now my default. My config file looks as below (ish) and I’ve much more flexibility on how I use git, notice that I’m using the same value for host as I am the standard login as the only difference in this instance is the user:

# Account for user1 - no link modification required
Host bitbucket.org
   HostName bitbucket.org
   IdentityFile ~/.ssh/user1
# Account for user2 - used for host amendment
Host user2.bitbucket.org
   HostName bitbucket.org
   IdentityFile ~/.ssh/user2
# Account for user2 - used for username amendment
Host bitbucket.org
   User user2
   HostName bitbucket.org
   IdentityFile ~/.ssh/user2

The outcome of this is that you now have a choice as to how you amend your ssh clone links, you may use that mentioned above or you can simply change the user at the beginning from ‘git’ to ‘user2’ in this example.

JBaker

Joi is an IT Development Analyst working in London and a consummate technophile. Whilst he isn't coding he can be found reacquainting himself with his guitars, spinning poi, looking for climbing walls or chasing the latest shiny thing to cross his field of vision.

Leave a Reply

Your email address will not be published. Required fields are marked *