Better support for multiple SSH keys

By on October 26, 2016

Alongside your professional “day job” Bitbucket account, you may just have a personal Bitbucket account where you’re building silent iPhone 7 games, hacking on the first killer VR app, or training TensorFlow to write one for you. To access both accounts from one computer, you’ve either had to use HTTPS for repositories belonging to your second account, or mangle your SSH config in order to provide the right key for the right clone. All whilst wondering why your repository’s SSH URL is prefixed with the seemingly redundant or

Moonlighters, I have good news for you! You can now prefix your repository URL with your Bitbucket username to easily use different SSH keys with different accounts. Simply clone from and Bitbucket will use the correct key proffered by your SSH agent.

To update a local repository to specify your username in the clone URL:

# determine your Git clone URL
$ git remote -v
origin (fetch)
origin (push)

# replace git@ with your-username@
$ git remote set-url origin

If you haven’t already, you can easily generate a second SSH key for your alternate account:

# generate and add a new SSH key
$ ssh-keygen -f ~/.ssh/your-username
$ ssh-add ~/.ssh/your-username

(You’ll also need to add the contents of ~/.ssh/ as a new Bitbucket SSH key.)

ssh-add adds the key to your local SSH agent, which Git and Mercurial will use automatically when interacting with a remote repository over SSH.
During key exchange, your SSH agent offers all the keys that may be appropriate for a particular host. Using git@ as a prefix means Bitbucket doesn’t know which user you’re attempting to authenticate as – so it accepts the first key that it recognizes. If this key belongs to your professional account, and you’re attempting to access a personal repository (or vice versa), you’re outta luck. Using your-username@ as a prefix allows Bitbucket to filter down which SSH keys should be accepted for a particular request.

If you have but a single Bitbucket account – no need to do anything. For backwards compatibility (and supporting things like deployment keys) git@ and hg@ will continue to work for the foreseeable future.

Happy moonlighting!