Re: Multiple Keys in ssh-agent, fail to clone

[Benjamin Fritsch]

> On Jul 13, 2016, at 3:32 PM, Junio C Hamano  wrote:
> 
> Benjamin Fritsch  writes:
> 
>> I read the Changelog for 2.9 and couldn’t find any reference to changed key 
>> handling. Is there anything that I can add to the `git clone` command to get 
>> the old behavior?
> 
> I do not think this has much to do with the version of Git, unless
> you are getting an updated SSH client together with your new version
> of Git from whoever distributes it.

Thank you for the great feedback. I could confirm that this is a problem on 
Bitbucket’s end. Sorry for the confusion.
I managed to successfully clone with Git 2.9 and Git 2.8

Best,
ben--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Multiple Keys in ssh-agent, fail to clone

[Johannes Schindelin]

Hi Benjamin,

On Wed, 13 Jul 2016, Benjamin Fritsch wrote:

> I have two keys.
> - KeyA (my company that has access to the repository I want to clone)
> - KeyB (just my personal key with access to my personal stuff)
> 
> Having both keys in loaded and listed in `ssh-add -L` fails to clone the
> repository. I tried to change the order of the key in the agent but
> neither KeyA, KeyB nor KeyB, KeyA will work. The only case that works if
> I have KeyA loaded an no other key is added to the ssh-agent.

I once had the same problem, due to a server newly closing the connection
directly after the first key failed. Note: the problem was the *server*
(that was updated at the same time as my local Debian packages).

The only remedy was to specify the exact key in ~/.ssh/config via
IdentityFile.

Hth,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Multiple Keys in ssh-agent, fail to clone

[Junio C Hamano]

Benjamin Fritsch  writes:

> I read the Changelog for 2.9 and couldn’t find any reference to changed key 
> handling. Is there anything that I can add to the `git clone` command to get 
> the old behavior?

I do not think this has much to do with the version of Git, unless
you are getting an updated SSH client together with your new version
of Git from whoever distributes it.

And it may not even be related to SSH version.  Did you change your
~/.ssh/config recently by any chance?  I personally do load many
keys (one per destination) in the agent and back when I didn't know
better, I didn't have IdentityFile line per each host, i.e. the last
lines in these two entries were missing in my ~/.ssh/config:

Host foo.bar.com
  Protocol 2
  User gitolite
  IdentityFile ~/.ssh/foo-bar-com

Host foo.baz.com
  Protocol 2
  User junio
  IdentityFile ~/.ssh/foo-baz-com

If you try to do "ssh -v -v foo.bar.com" with such a configuration,
you would observe that many keys are "offered" to the other side to
see if it is the one that it recognises, and you end up offering too
many of them before the right one.  An output from such a failing
session of "ssh -v" ends like this for me:

$ ssh -v foo.bar.com
...
debug1: Offering DSA public key: foo-baz-com
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: xxy-fsa-com
debug1: Authentications that can continue: publickey
debug1: Offering DSA public key: github
debug1: Authentications that can continue: publickey
debug1: ...
debug1: Offering RSA public key: gitorious
debug1: Authentications that can continue: publickey
Received disconnect from 192.168.1.1: 2: Too many authentication failures 
for gitolite
Disconnected from 192.168.1.1

If I do not have "IdentityFile ~/.ssh/foo-bar-com" line for the
"Host foo.bar.com" part, "ssh -v foo.bar.com" cannot know which
one of the keys it has available can be used to authenticate you
with foo.bar.com, so it ends up asking "do you know this key and
would you allow me to access you?" for each and every key.  Having
the line lets it use the appropriate key right at the beginning,
would not leak (they are "public" keys, so "leak" is not that a
serious problem, though) other public keys you have, and your
authentication is likely to succeed.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Multiple Keys in ssh-agent, fail to clone

[Benjamin Fritsch]

Hey all,

We recently upgraded from Git 2.8 to 2.9 and saw an issue when there are 
multiple keys added to my ssh-agent.

I have two keys. 
- KeyA (my company that has access to the repository I want to clone)
- KeyB (just my personal key with access to my personal stuff)

Having both keys in loaded and listed in `ssh-add -L` fails to clone the 
repository. I tried to change the order of the key in the agent but neither 
KeyA, KeyB nor KeyB, KeyA will work. The only case that works if I have KeyA 
loaded an no other key is added to the ssh-agent.

Having multiple Keys loaded works with Git 2.8 and Git 2.7 (I didn’t try older 
versions)
Cloning fails with “Unauthorized Access” of our Git provider. (It’s Bitbucket 
in this case)

I read the Changelog for 2.9 and couldn’t find any reference to changed key 
handling. Is there anything that I can add to the `git clone` command to get 
the old behavior?

Thank you for your help,
Best
Ben--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html