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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Benjamin Fritsch <beanie@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]