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

[Michael Crawford]

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!

[kenn-cal]

I've come across this answer on StackExchange:

https://superuser.com/questions/879050/sourcetree-ssh-options-on-os-x

[Deleted user]

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.

[Erick Franco]

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

ssh-add -K ~/.ssh/id_rsa

Steps:

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

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

2. Copy your new generated key with:

pbcopy < ~/.ssh/id_rsa.pub

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.

[Rebecca Hellström Karlsson]

This link worked like a charm for me as well!

[Fabio Tiriticco]

Thanks! 

[nguyen doxuan]

Thanks, it's working for me.

[Laura Mejia Arroyave]

Thanks!

[designbynina]

Worked, thanks!

[Thau Nguyen]

thanks

[Angga Indriya Pamungkas]

This is worked for me. Thanks

[Cristian Rojas]

Thank you. It worked out ;-)

[Shobhit Chourasia]

Thanks

[arag0re]

actually worked, thx 

[Shrikant]

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

[apachor]

Tools -> Options

Under General Tab - SSH Client Configuration

1. SSH Key: Give path to your SSH key

2. SSH Client: Change to OpenSSH

[sscholle]

The procedure described above does not work for Mac.

[apachor]

Thanks for trying on Mac @sscholle. 

At least this works for Windows

[aaronbartell]

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.

[Shafiq Shaar]

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.

[Jacob Andersen]

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/jacobandersen-Bitbucket.pub)
3. and made copies of the correct key files (in my case ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub) 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 / id_rsa.pub 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

[Hack Kampbjørn]

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

[Jordan Kintzle]

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

[Stanisław Kożuchowicz]

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

[Anthony Camilo]

I cna confirm what Stanislaw said. Symlinks work.

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

[Michael Crawford]

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.

[JDFagan]

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 MyPreferredKey.pub bbusername-Bitbucket.pub
ln -s MyPreferredKey ghusername-GitHub
ln -s MyPreferredKey.pub ghusername-GitHub.pub

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

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

[Marlon (esolitos)]

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.

[tybaldwin]

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. 

[Marlon (esolitos)]

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

[manolesc_test]

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

[sscholle]

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

ssh-add -K ~/.ssh/id_rsa

Thumbs crossed!

[Cesar Garcia]

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.

[Ad Sua]

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

[Andre Henriques]

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?

[Dmitry Shevchyshen]

It helped me (on windows)
https://www.digitalocean.com/community/tutorials/how-to-use-pageant-to-streamline-ssh-key-authentication-with-putty

[dkav]

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

Host github github.com
 HostName github.com
 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 :

github.com:your_username/repo.git

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

[sscholle]

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!

[Jerry W]

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.

[Jerry W]

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

[Kenneth Hurley]

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.

[Francois Rigaut]

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.