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

SourceTree Error: remote: Permission denied (publickey).

All of a sudden I can no longer push or pull from bitbucket from my local copy. I keep getting "remote: Permission denied (publickey).". Whats even more odd is that I can push/pull just fine from the Terminal. Im using the latest version of SourceTree from the website (non-App store version - Any idea whats going on?


UPDATE: I did some more snooping around and tested my Terminal connection (which I knew already worked). Here's the output:

$ ssh -T
conq: logged in as xxxxx.

You can use git or hg to connect to Bitbucket. Shell access is disabled
So this problem seems to be limited to the SourceTree application only. Help!

Update 2: I've even tried removing my old SSH key and adding a new one. Again my terminal commands work fine, just SourceTree doesn't work.

9 answers

I had the same problem. SourceTree couldn't connect to my git repo while using git commands in terminal was working. I added the custom action Steve suggested above and realized that the error came from my computer password not saving. 

To solve it, I added the following line at the top of my `~/ssh/config` file:

Host *

    UseKeychain yes

That solved the authentication problem.

Along the way, I also fixed a couple of issues by going through this page. For example, I had 2 ssh-agents running concurrently. 

@Abbas SarrafThank's bro ! Works perfetly

I just ran a quick test here (SourceTree itself is hosted on Bitbucket and I use SSH keys) and nothing seems to have changed behaviour, at least in terms of SourceTree and Bitbucket. I don't understand how the behaviour could differ between SourceTree and the command line since they both use the same underlying SSH implementation, and the configuration comes from the same place.

The only thing I can think of is that perhaps you have some environment changes that have only affected GUI apps and not the terminal (or vice versa); for example have you made changes to your terminal profile (which GUI apps would not pick up), or to ~/.MacOSX/Environment.plist (which the terminal would not pick up)?

The other possibility is that the ssh agent has an old cached key in it which is being rejected, a restart would ensure that's cleared.

Thanks for the quick reply Steve. With regards to your answers:

1) The modification time on Environment.plist is Oct 2008. Does that rule this possibility out? This started happening last week.

2) I tried restarting ssh-agent, no go. I have three keys in the agent, so I removed all of them and added only the bitbucket key as I noticed having 3 or more keys sometimes causes issues with remote servers. No go there either.

This is a pain in the butt. Although as a result I've learned more about using hg on the command line :) Any other ideas?


I'm quite baffled I'm afraid, in the past 2 years I've never seen this fail to just reflect terminal SSH behaviour. Just as a last resort I would try restarting your entire Mac just in case.

One thing that might shed more light is to run some commands from within SourceTree itself to diagnose what might be different - the Custom Actions option can help here. So in Preferences > Custom Actions, you could try creating some simple terminal commands which might expose some more information about what's being rejected.

You could start with your ssh command, setup something like this:

Menu Caption: Debug SSH
Show Full Output: Yes
Script to run: /usr/bin/ssh
Parameters: -vvv

You can then launch that from Actions > Custom Actions > Debug SSH. If that fails, maybe it will give you more information about why it's different.

Steve you're the man! Creating the custom action allowed me to see the debug output I needed. Not sure why SourceTree's SSH output was different than what I was seeing in Terminal, but it was trying keys that didn't exist. The fix was to edit my /etc/ssh_config file and add:

  IdentityFile ~/.ssh/id_rsa_bitbucket

Thanks again!

Awesome, glad to help :)

This is great - setting this manually worked for me also:

  IdentityFile ~/.ssh/id_rsa_bitbucket

(where id_rsa_bitbucket is the private key)


Seems to be a bug in SourceTree.

Thank you Steve. After running your custom action, I saw SourceTree read my config file, then skipped it and went to etc/ssh/ssh_config and used Host *.  So I edited my config file that had Host (my key name) and removed the key name and changed to Host *.  Now it is working.  Been trying to figure this out for a week!   

This is a bit frustrating :-( For the past two days all was working well. Started work this morning and getting fatal erros again brom both at the command line and in SourceTree. My ssh signature has not changed, but I restet it in BitBucket jic. I get

germante:thatsit joel$ git push
conq: repository access denied. access via  a deployment key is read-only.
fatal: The remote end hung up unexpectedly

In SourceTree I get

git -c diff.mnemonicprefix=false -c core.quotepath=false push -v --tags origin master:master 
Pushing to
conq: repository access denied. access via  a deployment key is read-only.
fatal: The remote end hung up unexpectedly
Completed with errors, see above

To make things worse I noticed today that my repos structure looks corrupt. The origin-https/ where remotes I tried adding to explore what was and was not working the other day. Cannot seem to get rid of them. I really do not understand the progression in the first line of the screenshot.

Possibly my best coarse of action now is to simply blow away the repository, create a new one and start over. Can I do that without removing my local repos which contains my history.

I would like to understand why I am having these issues though :-(

Many thanks,


Your repo is not corrupt, you don't have to delete it. What's happened is that you've fetchedremote references called 'origin-https' and they stay once fetched until you 'Prune' them. If you want to get rid of them, make sure origin-https is gone from your remote configuration and then use the 'Fetch' toolbar button and check the 'Prune' option.

As for your access problems, I think you've got confused between the SSH keys you use to commit, and 'deployment keys', which are something entirely different. Please see for details of what a deployment key is. I suspect you've set up your SSH key as one of those instead of your main user SSH key.

Once again Steve thank you for you patience.

I followed your instructions and *everything* is now working great :-)

The problem was, of course, me. Never trust and an old seasoned developer when he forgets he really does not understand everything :-( This is my first real experiance with Git, no less BitBucket and SourceTree. I thoguht I had understood the scheme of things after a quick read of of the getting started guide and failed to read carefully or at sufficient depth for the occasion. The result, as always, was unnessary wasted cycles trying to figure out why *it* did not work. Well, once again, the same lesson well learnt.

Sorry for the inconvenience but maybe the thread will hope some other lost souls along the way.

All the best,


PS - thanks also for the great products and services. BitBucket and SourceTree really rock :-)

As an old seasoned developer myself, I can say it happens to us all :) Glad to help, and it's great to hear you're enjoying using Bitbucket and SourceTree!

That's quite clear now. Thank you for the explanation. Now if I can only get Xcode to access my Bitbucket repo all would be perfect. But I am actually prepared to live without that as Xcode's support for git is fairly enemic in any case.



Yes you are absolutely correct. Thanks all is fine with SourceTree now :-)

What I still do not understands is why I can (once again?) push at the command line, BUT ssh -v still fails with Permission denied (publickey).

It's because SSH access to repositories is actually done via the hg@ and git@ URL forms, not yourusername@ (perhaps slightly confusingly, for https you do use your username).

The reason is that your actual username is derived from your public key via a matching process after the initial SSH connection is made via the hg or git user. You essentially have no access via SSH to via your own username at the front-end. This is actually pretty common when using SSH to access git/hg, because it means the server doesn't have to update its SSH configuration for every new user, just the back-end repo configuration.

No actually the settings are correct.

The reason I used the hg was simply because that what was given in the post that a copied from. ssh -v also succeeds okay, though. It appears that the issue shows up on writing back to the repository fro either the command line or SoruceTree.

The settings aren't correct - compare them with the URL displayed in bitbucket when you click the 'Clone' button with SSH selected.

Seriously, change the URL from ssh:// to . The latter is the correct SSH URL, your username is derived from matching the SSH key.

Thanks that added grist to the mill. Found out that ssh -v fails with a Permission denied (publickey) but git clone succeeds fine. I have deleted and reset reset my default public key on bitbucket to no effect.

Ahh, the plot thickens. My repo is setup as private. I have removed my ssh key from my Bitbucket account and I can still clone. Obviously I do not understand the rules as to when Bitbucket needs ssh verification.

Any ideas,


Ah, I think I was confused by your testing of If this is a git repo on Bitbucket, you should use the URL for SSH. It looks like your remote is set up incorrectly on your local repo, just hit the Settings button in the top-right of the repo window in SourceTree and change the remote URL to that instead.

Sorry it turns out that was a red herring. Cut and pasted the command into the action and got a leading space in it that caused the provlem.

Now I have output from the action the verifies the connection is made and succeeds. See attacged file for output.


And the output from my push that fails is in the file


This is obviously a show stopper for me and I would appreciiate any ideas and assistance.



I think you need to check 2 things:

  1. That you've correctly added your public key to your Bitbucket account
  2. That the account has access to the repository

You might be able to prove this more accurately using instead of in your simpler debug test.

The thing is, when using SSH with git via the general, the private key is used not only to authenticate but also to identify your user name. If this fails, it just lets you in as an anonymous user, which can obviously only see public repositories. So the test of SSH with doesn't actually prove that your SSH key is set up correctly and that you have permission to this repo.

I am having the same problem. I have worked through the debug steps Steve suggested. When I run the command '/usr/bin/ssh -vvv' I get copious output and the command is successful. When I run the custom action I get:

ssh -vvv 
launch path not accessible
Completed with errors, see above

Any suggestions on where to go from here??



Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Sourcetree

Bug Fix: Sourcetree for Windows authentication error when updating to app password

Hello Sourcetree users!!! With the recent removal of Bitbucket Cloud account passwords for app passwords (please see our Bitbucket Cloud community post for details on why we made this change for se...

61,926 views 127 27
Read article

Community Events

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

Events near you