Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

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!

14 answers

Deleted user Jun 23, 2017

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.

Like # people like this

This link worked like a charm for me as well!

Thanks, it's working for me.

Worked, thanks!

This is worked for me. Thanks

Thank you. It worked out ;-)

actually worked, thx 

Not working for SourceTree 4.1.3 I tried adding ssh key to the keychain.

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 @sscholle

At least this works for Windows

Like Alousseni Maiga likes this

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.

Like Albert van der Meer likes this

I can confirm it worked on Windows 10. In fact, I didn't have to do step 1. I changed to OpenSSH and it automatically picked my id_rsa key.

Like # people like this

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. 

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.

At lease for me, the issue was the the ssh agent used by Sourcetree did not have the key loaded. 

I fixed this by:

  1. Click the Console button
  2. In the new CLI console, type
    ssh-add -K ~/.ssh/<git_key_name>
  3. Back in the Sourcetree UI, try doing a fetch and verify the log output

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.

Sebastian, thank you!!!!! it works :)

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?

Remove your duplicate certs and add something like the following to your .ssh/config file:

Host github
User git
IdentityFile ~/.ssh/your_github_cert

For my setup, the remote origin url must not include ssh://. Based on the above ssh config, here is what worked for me :

The application will have an SSH ! symbol in Preferences - Accounts but this doesn't hinder access via the method outlined.

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!

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

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.

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.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events