How can I use my existing default ssh key with SourceTree?

I just rebuilt my laptop and iMac with clean installs of MacOS Sierra. I normally use the command line git client to work with GitHub or BitBucket. I'm on a new project where I have to collaborate with some people on Windows and suggested they use SourceTree, and wanted to re-install SourceTree on my macs so I could help them learn this by demonstration, as I have used this from time to time in the past.

It seems there is some change to how the setup and configuration of SSH keys work. Before, I could pick one of my ssh keys (I have dozens, but mainly use one for work and another for personal Git repos) during setup. Now, I get a message "no key found", despite the fact I have ~/.ssh/id_rsa defined, it's in my agent and Apple keychain, and I can use this fine everywhere else.

I used to be able to use this with SourceTree. Now, I see no way to specify this key, it's not being found despite being in the normal location on Mac/Linux systems, and it seems the only way to use ssh is to generate a new ssh key - WHICH I DO NOT WANT TO DO. Why can't I use the ssh key which I want to use? Why isn't this finding my default ssh key like all other programs I have which use ssh, including earlier versions of SourceTree.

Not letting me use my existing ssh key is a recipe for losing me as a customer - I don't like being forced to change the way I work. There should be a way to specify the location of an existing ssh key!

11 answers

Thought I was going crazy, but I see I am not the only one with this issue...

I have been fighting this today and just ended up with an ugly fix:

  1. allowed SourceTree to generate the keys
  2. deleted the newly generated key files right away (in my case ~/.ssh/jacobandersen-Bitbucket and ~/.ssh/
  3. and made copies of the correct key files (in my case ~/.ssh/id_rsa and ~/.ssh/ with the names above.

Thus ending up with two identical sets of keys in my ~/.ssh

Ugly, but it seems to work...

And no, it has nothing to do with the length of the keys - my keys in id_rsa / were also much shorter than the keys generated by SourceTree. It seems SourceTree will only accept keys in files named by the pattern username-Bitbucket.

Hope it will help

This worked for me too. Although I used symlinks instead of copy

Worked for me as well. I thought I was going crazy. Thanks!

Instead of copying your keys, you can create appropriately named symbolic links. This worked for me.

I cna confirm what Stanislaw said. Symlinks work.

ln -s .ssh/id_rsa .ssh/yourbbusername-BitBucket
ln -s .ssh/ .ssh/

Another option, and the one I chose, is to switch to Github Desktop, as I really don't like a software vendor who breaks existing, widely-expected intuitive behavior without warning, and then ignores customer complaints about it for months.

That's the reason I haven't come back here since my original post, until getting another message today from this thread and getting curious.

Good to know symlinks work, should I ever decide to give these guys a chance again. But to be honest, until they restore an ability for me to use MY OWN NAMING CONVENTION for the dozens of ssh keys I have to deal with, I have no interest in giving them another chance.

In fact, I've also signed up for a small corporate plan on GitHub and have moved most of my new work there instead of BitBucket, so that I can more effectively use GitHub Desktop or their GUI for Pull Request management, something prompted largely due to this irritation.

I'm quite disappointed with this engineering decision, but even more so, the fact they haven't corrected what I along with most other people on this thread think is an obnoxious interference into how experienced developers work.

Agree with Stanislaw and Anthony, symlinks worked great for me, but I did have to reboot my computer for it all to work seamlessly within SourceTree.  In my case, I wanted to re-use keys across different accounts and used the following:

cd ~/.ssh
ln -s MyPreferredKey bbusername-Bitbucket
ln -s
ln -s MyPreferredKey ghusername-GitHub
ln -s

 Also, don't forget to add your private keys via ssh-add after reboots:

ssh-add ~/.ssh/MyPreferredKey
ssh-add -l


Symlinks are *not* a solution, it's merely a workaround for a bad hardcoded behaviour of Sourcetree.
I have over 100 repositories, i seriously cannot be required to create 200+ symlinks, jsut because people at Atlassian decided that using my ssh configuration is not good enough.

Don't get me wrong, I do like this option for unexperienced users, it slighly increases security creating separate keys per repos, but this cannot prevent me to handle my configuration if i know what I'm doing.

Right now I have basically fallen back to git via cli, except for some more advanced actions ( which i simply cannot be bothered to rememer the exact git syntax :) ), another bad thing which happened lately on ST is the crazy performance drop in displaying the diff, which used to be extremely swift.

I second this concern. Since upgrading to the latest version of SourceTree, I can no longer use my existing keys. I had all of my GIT repos for work stuff set to one key, while all of my personal stuff used another. Now I need to go through and reset ALL of my other repos in order to match the new key because SourceTree no longer allows me to use my existing key. This is poor programming at its finest. 

4 votes

Tools -> Options

Under General Tab - SSH Client Configuration

1. SSH Key: Give path to your SSH key

2. SSH Client: Change to OpenSSH

The procedure described above does not work for Mac.

Thanks for trying on Mac @Sebastian Scholle

At least this works for Windows

This worked for me on Windows 10 and should be the most upvoted answer at this point because it isn't a work-around.

Too bad OpenSSH isn't the default in SourceTree.

While @Jacob Andersen suggestion is a good workaround i still think it's a bit crazy to enforce this behaviour from Atlassian.

Don't get me wrong, I like that an inexperienced user will create keys that only have access to a specific repository, but there's no "opt out" option. I personally like to have dedicated keys per service, but I want to have the freedom to do that myself not being treated by a complete idiot by a software. smile
Of course i can use git from cli, and for a good amount of actions I actually do, but SourceTree (and similar softwares) help in "tricky" situations.

This linked solution by Justin Toman solved the problem for me, and didn't involve any hocus-pocus with file names. I've yet to see if I have to re-enter my password on system reboot, but so far it looks like a quick, complete solution.

As Mac user. The solution from the link above worked me. 

ssh-add -K ~/.ssh/id_rsa



1.  Ensure you have a SSH key first.  Or create one on the command line:

ssh-keygen -t rsa -b 4096 -C ""


2. Copy your new generated key with:

pbcopy < ~/.ssh/


3. Login to bitBucket and go to Setting -> SSH. Add a new key by Pasting it!


4. Now go back to your command line and type

ssh-add -K ~/.ssh/id_rsa

5.  DONE. You can now open source tree and clone a branch.

This link worked like a charm for me as well!

I am also seeing this issue as my SourceTree updated to Version 2.4 (96) and now my ssh keys are not found. For the short term, I've swapped over to HTTPS, but it's not my ideal solution. Has anyone found a better solution to link to the original .ssh keys?

Same here. I find SourceTree the most suited to my need, but the authentication and ssh really have issues. As for connecting it to GitHub, not even succeeded once.

Regarding the ssh key: Wondering if perhaps source tree internal policies have changed and they require the key to be of a minimum length? I noticed the one generated with the "generate ssh key" inside SourceTree is longer than my default key.

Ran into the same issue.  What a truly bad decision on Atlassians part to force you to use a specific name for your ssh key files. 

It should allow you set the files, like it used to do.

Is someone from Atlassian reading this forum?

I've searched for a way to put this issue into a jira ticket. But I haven't found anything. 

This behaviour is really annoying. Stops me from using sourcetree.

I think I've solved my problem using .ssh/config to set a specific key for

MacOS - Been struggling since forever with Mac builtin SSH compatability with Sourcetree. I've almost always had to resort to using HTTPS connections as they gave much less hassle.

Have now resorted to using Command line Git.


Sourcetree devs needs to WAKE UP!

My second answer is the correct one thanks to @Kenn Gerard Cal.

ssh-add -K ~/.ssh/id_rsa

Thumbs crossed!


I had the same problem.

This worked for me on macOS 10.12.6

Just closed and re-open SourceTree after running the command above and it connected to Bitbucket repositories.

Suggest an answer

Log in or Join to answer
Community showcase
Brian Ganninger
Published Jan 23, 2018 in Sourcetree

Tip from the team: workflow and keyboard shortcuts

Supported Platforms macOS Sourcetree has a lot to offer and, like many developer tools, finding and using it all can be a challenge, especially for a new user. Everyone might not love ...

232 views 0 3
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot