nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Only the top listed private key in Pageant is used/offered (by Git/SourceTree/TortoiseGit?).

Robertino Value

I spent a whole day trying to trace the source of this error :

QUOTE

Permission denied (publickey).

fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists."

UNQUOTE

I already tried all the usual suspects listed around the net, and at Atlassian and Github. To no avail.

I usually have about 8 - 10 SSH private keys loaded in Putty Pageant. And I do NOT get this error with Putty and WinSCP. With these 2, I can login over SSH with any number of different SSH identities, simultaneously.

But with TortoiseGit 1.8.0.0 (trying to login to just 1 account) I started seeing this error when I updated msysgit to 1.8.0.0.
I started creating my first 3 repos on Bitbucket 2 days ago. I had 10 SSH keys loaded in Pageant, and I was able to only connect to one Bitbucket account over SSH to push, etc. The other 2 received the error message above consistently.

The issue is easy to reproduce. Remove all private keys from the list in Pageant, and add just the 3 SSH identities meant for logging into Bitbucket. Any Git activity which requires login for the second and third keys will always fail. Remove the top key, and the second one (now at the top) will authenticate without issue. And the third on its own of course will always work. Doing this with just 2 private keys in the list (in all possible combinations of the 3 private keys) gives the same results. The one at the top is always used/offered to any request. Anything below it is not used/offered.

With only one of the 3 private keys in the list, there is never a problem as long as you attempt to login to the corresponding account. When attempting to login to a non-corresponding account, Pageant sometimes pops an error "Couldn't load this key (unable to open file)". After pressing OK to dismiss the error popup, the push would fail with the "Permission denied (public key)" error. I usually get this error when I try to load a public key into Pageant. That's why it's so weird.

I first saw this with TortoiseGit 1.8.0.0 and msysgit 1.8.0.0. Upgrading to 1.8.1.0 and 1.8.1.2 respectively didn't change a bit. So I blamed Tortoisegit and completely uninstalled and ran CCleaner to rid off most.

I installed SourceTree, and experienced the same problem. I have to make sure that the private key of the repo I want to work with is at the top of the list in Pageant. Which pretty much negates the multiple Repo tabs in SourceTree.

So I suspect that this is a Git problem. What I'm looking for is confirmation. I'm about to bury DVCS again, for another 3 years or so.

Accepted answers

stevestreeting

[Reposting comment as an answer]

I've re-tested this and I can reproduce your case now, it only occurs when you have multiple *valid* keys for the host, ie keys that are associated with users on Bitbucket. And this now makes perfect sense, because what happens is that when you connect, BB asks for a key and Pageant passes the first one. Because that key *is* actually valid for a user on BB, it accepts it and logs you in as the user associated with that key. It then tries to get access to the repository - and fails because that user, while validly authenticated on BB, is not allowed access to that repo. It's only if the key that's passed to BB *isn't* a valid BB user than it moves on to try the next one.

I can actually reproduce this on the command line too, it's not a SourceTree issue. But then, I have my GIT_SSH pointing at plink.exe - I suspect that it's working for you in Git GUI because you're actually not using Plink/Pageant for that connection, perhaps you're using OpenSSH instead and there's some config for that that's resolving the ambiguity (IdentityFile).

One way to resolve this is to perform the same configuration in PuTTY too to disambiguate what key to send (and therefore which user to authenticate as).

Start PuTTY (download it from putty.org if you don't have it)
Type 'bitbucket.org' in the host name field
Go to Connection > SSH > Auth in the tree
Specify the key to use for the BB user
Go back to 'Session' in the tree
Type an alias name underneath 'Saved Sessions' (e.g. bb-user1) and Save
Repeat 2-6 for each BB user and save as a different session name

Then in your remote URLs, replace 'bitbucket.org' with the session name (e.g. bb-user1) to disambiguate what SSH key to send first. This is identical to using IdentityFile in OpenSSH.

All comments

stevestreeting

Hmm, I can't reproduce this. I usually only have one key that I use, but I generated 2 others and tried a variety of orders and it didn't matter where my real key was in the list, it always got picked up. It seems that the Pageant list orders by bit length first, so after trying comment or key name that's how I eventually ordered them, although just in case I tried other combinations of fields too. It didn't matter, my proper key which was either 2nd or 3rd on the list always authenticated me fine.

I was testing with Bitbucket's SSH by the way. I don't know if it's possible that some servers only allow one key to be tried by the client before rejecting the connection, if so perhaps that's why you had this issue.

If that is the case then you may be able to make this more predictable by connecting though a PuTTY 'session' instead of the raw server name (session == alias) which specifies which key to send. You still need to use Pageant, but it will probably make it try the right key first. You do this by downloading the full PuTTY client from http://www.putty.org, running it then defining a session:

Type the host name in the top field
Go to SSH > Auth in the tree
Specify the key in 'Private key file for authentication'
Go back to the 'Session' section, type a session name under 'Saved Sessions' and click Save

Then you use this session name instead of the host name to connect, and it will pick up these settings.

Robertino Value

Apologies for the late reply, but I'm not getting email updates for this question. Strange.

You mention that you usually have one key that you use. That's why you're not getting the error because you're using the same SSH key for all repos/projects.

I'll be more specific. I have for instance 4 tabs/repos opened in SourceTree, across 3 Bitbucket accounts. This forces me to use 3 SSH keys. For example, I push to Bitbucket from tab 1. Pageant offers the corresponding private key, and all is well. But now I want to push to Bitbucket from tab 2 (another BB a/c), and it fails as described. Pushing to bitbucket from tabs 3+4 (yet another BB a/c) also fails. In this particular situation, I can only make git actions from tab 2, and tabs 3+4 work when I make sure that Pageant finds their key first. So I remove the SSH key for tab 1 from Pageant. Push from tab 2, and then add the SSH key for tab 1 again when I'm finished with tab 2. Same for tabs 3+4.

It looks like that on the very first git action (push, clone, whatever) the SSH key offered by Pageant is accepted and used for all opened tabs/repos.

That's also what's causing the confusion about the key sequence/order. The first git action always results in successful authentication. The problems start when after that, trying to simultaneously perform git actions to a repo with another SSH key.

Robertino Value

About what I wrote in my first post, "I have to make sure that the private key of the repo I want to work with is at the top of the list in Pageant.". I wrote "...at the top..." because I did not load the other 7 keys into Pageant. So there is always 1 Bitbucket SSH key at the top. When the other 7 keys are also in Pageant, the 3 BB keys sit somewhere in the middle, and still, only the first of the 3 is OK'ed. I was just taking the other 7 keys out of the equation to make things easier.

Like I mentioned at the end of my first post, for me, this pretty much negates the multiple Repo tabs in SourceTree. Especially, because after reporting this, I found out through trial and error that with Git Gui I can just start a new instance/session of Git Gui for each repo and can work on as many projects simultaneously as I want/can manage. As long as the keys are in Pageant. I thought that each SourceTree tab would be the equivalent of a Git Gui instance/session, without the clutter of 4/5 Git Gui windows opened.

stevestreeting

[Reposting comment as an answer]

One way to resolve this is to perform the same configuration in PuTTY too to disambiguate what key to send (and therefore which user to authenticate as).

Start PuTTY (download it from putty.org if you don't have it)
Type 'bitbucket.org' in the host name field
Go to Connection > SSH > Auth in the tree
Specify the key to use for the BB user
Go back to 'Session' in the tree
Type an alias name underneath 'Saved Sessions' (e.g. bb-user1) and Save
Repeat 2-6 for each BB user and save as a different session name

Then in your remote URLs, replace 'bitbucket.org' with the session name (e.g. bb-user1) to disambiguate what SSH key to send first. This is identical to using IdentityFile in OpenSSH.

stevestreeting

There isn't any relationship between tabs and keys used - all SourceTree ever does is call git commands, and git has absolutely no idea which tab that came from or the existing context - there's nowhere that we specify what SSH key to use for example.

One way to resolve this is to perform the same configuration in PuTTY too to disambiguate what key to send (and therefore which user to authenticate as).

Start PuTTY (download it from putty.org if you don't have it)
Type 'bitbucket.org' in the host name field
Go to Connection > SSH > Auth in the tree
Specify the key to use for the BB user
Go back to 'Session' in the tree
Type an alias name underneath 'Saved Sessions' (e.g. bb-user1) and Save
Repeat 2-6 for each BB user and save as a different session name

Then in your remote URLs, replace 'bitbucket.org' with the session name (e.g. bb-user1) to disambiguate what SSH key to send first. This is identical to using IdentityFile in OpenSSH.

stevestreeting

BTW you still need to load these keys into Pageant if they have passphrases on them. This just makes sure the right key gets sent in the first instance.

Robertino Value

And this now makes perfect sense, because what happens is that when you connect, BB asks for a key and Pageant passes the first one. Because that key *is* actually valid for a user on BB, it accepts it and logs you in as the user associated with that key. It then tries to get access to the repository - and fails because that user, while validly authenticated on BB, is not allowed access to that repo.

Well this doesn't make sense at all to me :

configured at Bitbucket :

A/c 1, repo 1 origin : git@bitbucket.org:username1/username1.bitbucket.org.git + SSH-pubkey-1

A/c 2, repo 1 origin : git@bitbucket.org:username2/username2.bitbucket.org.git + SSH-pubkey-2

A/c 3, repo 1 origin : git@bitbucket.org:username3/reponame.git + SSH-pubkey-3

A/c 3, repo 2 origin : git@bitbucket.org:username3/username3.bitbucket.org.git + SSH-pubkey-3

configured in SourceTree :

Tab 1 has origin address : git@bitbucket.org:username1/username1.bitbucket.org.git

Tab 2 has origin address : git@bitbucket.org:username2/username2.bitbucket.org.git

Tab 3 has origin address : git@bitbucket.org:username3/reponame.git

Tab 4 has origin address : git@bitbucket.org:username3/username3.bitbucket.org.git

configured (in sequence) in PuTTY :

SSH-privatekey-1

SSH-privatekey-4

SSH-privatekey-2

SSH-privatekey-3

So at authentication from tab 1, BB receives pubkey-1 from PuTTY, encrypts challenge msg, sends encrypted msg to PuTTY, receives decrypted msg from PuTTY. Accesses Repo. OK!

Then at authentication from tab 2, The same. ERROR!

Then at authentication from tab 3, The same. ERROR!

Then at authentication from tab 4, The same. ERROR!

Why do I have to specify a different SSH key for each BB-account?

If BB is going to access the Repo only with the first SSH identity sent by PuTTY. And then gives up after the first fail. One and the same SSH key for all my accounts would have been sufficient.

Robertino Value

I know for a fact that PuTTY can loop through the private keys loaded and authenticate with all that match the server. Because I bumped into the following problem a couple of years ago : http://the.earth.li/~sgtatham/putty/0.62/puttydoc.txt

10.5 Server sent disconnect message type 2 (protocol error): "Too many authentication failures for root"'

       This message is produced by an OpenSSH (or Sun SSH) server if it
       receives more failed authentication attempts than it is willing to
       tolerate.

       This can easily happen if you are using Pageant and have a large
       number of keys loaded into it, since these servers count each offer of a public key as an authentication attempt. This can be worked
       around by specifying the key that's required for the authentication in the PuTTY configuration (see section 4.20.8); PuTTY will ignore any other keys Pageant may have, but will ask Pageant to do the authentication, so that you don't have to type your passphrase.

       On the server, this can be worked around by disabling public-key
       authentication or (for Sun SSH only) by increasing `MaxAuthTries' in
       `sshd_config'.

Why can't SourceTree co-op with Pageant (like PuTTY and WinSCP) and ask for the next key until successful?

Or the second suggested option, store the path to a private key, per BB account, and ask Pageant to authenticate with that specific key?

(This is the reason that I can use PuTTY and WinSCP for multiple logins to the same server simultaneously.)

P.S.

About GitGui, I'm not aware of having setup any redirection or aliasing.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

sourcetree

permission

git

ssl