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!
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 "firstname.lastname@example.org"
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.
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:
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
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:
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:
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:
ssh-add -K ~/.ssh/<git_key_name>
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.
Remove your duplicate certs and add something like the following to your .ssh/config file:
Host github github.com
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.
A vulnerability has been published today in regards to Sourcetree for Windows. The goal of this article is to give you a summary of information we have gathered from Atlassian Community as a st...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events