{"thread":{"id":"42839","subject":"Multiple Keys in ssh-agent, fail to clone","startedAt":"2016-07-13T19:08:21Z","lastAt":"2016-07-15T12:05:14Z","messageCount":4,"participants":["Benjamin Fritsch","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"291383","messageId":"CFA91608-1F29-4631-BABC-258404A62A3B@benle.de","threadId":"42839","inReplyTo":null,"subject":"Multiple Keys in ssh-agent, fail to clone","fromName":"Benjamin Fritsch","fromEmail":"beanie@benle.de","sentAt":"2016-07-13T18:56:28Z","receivedAt":"2016-07-13T19:08:21Z","isPatch":false,"sender":{"key":"beanie@benle.de","avatar":null},"body":"Hey all,\n\nWe recently upgraded from Git 2.8 to 2.9 and saw an issue when there are multiple keys added to my ssh-agent.\n\nI have two keys. \n- KeyA (my company that has access to the repository I want to clone)\n- KeyB (just my personal key with access to my personal stuff)\n\nHaving 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.\n\nHaving multiple Keys loaded works with Git 2.8 and Git 2.7 (I didn’t try older versions)\nCloning fails with “Unauthorized Access” of our Git provider. (It’s Bitbucket in this case)\n\nI 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?\n\nThank you for your help,\nBest\nBen"},{"id":"291387","messageId":"xmqqziplz63l.fsf@gitster.mtv.corp.google.com","threadId":"42839","inReplyTo":"CFA91608-1F29-4631-BABC-258404A62A3B@benle.de","subject":"Re: Multiple Keys in ssh-agent, fail to clone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-13T19:32:46Z","receivedAt":"2016-07-13T19:33:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Benjamin Fritsch writes:\n\n> 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?\n\nI do not think this has much to do with the version of Git, unless\nyou are getting an updated SSH client together with your new version\nof Git from whoever distributes it.\n\nAnd it may not even be related to SSH version. Did you change your\n~/.ssh/config recently by any chance? I personally do load many\nkeys (one per destination) in the agent and back when I didn't know\nbetter, I didn't have IdentityFile line per each host, i.e. the last\nlines in these two entries were missing in my ~/.ssh/config:\n\n Host foo.bar.com\n Protocol 2\n User gitolite\n IdentityFile ~/.ssh/foo-bar-com\n\n Host foo.baz.com\n Protocol 2\n User junio\n IdentityFile ~/.ssh/foo-baz-com\n\nIf you try to do \"ssh -v -v foo.bar.com\" with such a configuration,\nyou would observe that many keys are \"offered\" to the other side to\nsee if it is the one that it recognises, and you end up offering too\nmany of them before the right one. An output from such a failing\nsession of \"ssh -v\" ends like this for me:\n\n $ ssh -v foo.bar.com\n ...\n debug1: Offering DSA public key: foo-baz-com\n debug1: Authentications that can continue: publickey\n debug1: Offering RSA public key: xxy-fsa-com\n debug1: Authentications that can continue: publickey\n debug1: Offering DSA public key: github\n debug1: Authentications that can continue: publickey\n debug1: ...\n debug1: Offering RSA public key: gitorious\n debug1: Authentications that can continue: publickey\n Received disconnect from 192.168.1.1: 2: Too many authentication failures for gitolite\n Disconnected from 192.168.1.1\n\nIf I do not have \"IdentityFile ~/.ssh/foo-bar-com\" line for the\n\"Host foo.bar.com\" part, \"ssh -v foo.bar.com\" cannot know which\none of the keys it has available can be used to authenticate you\nwith foo.bar.com, so it ends up asking \"do you know this key and\nwould you allow me to access you?\" for each and every key. Having\nthe line lets it use the appropriate key right at the beginning,\nwould not leak (they are \"public\" keys, so \"leak\" is not that a\nserious problem, though) other public keys you have, and your\nauthentication is likely to succeed.\n"},{"id":"291406","messageId":"alpine.DEB.2.20.1607141007230.6426@virtualbox","threadId":"42839","inReplyTo":"CFA91608-1F29-4631-BABC-258404A62A3B@benle.de","subject":"Re: Multiple Keys in ssh-agent, fail to clone","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-07-14T08:09:28Z","receivedAt":"2016-07-14T08:09:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Benjamin,\n\nOn Wed, 13 Jul 2016, Benjamin Fritsch wrote:\n\n> I have two keys.\n> - KeyA (my company that has access to the repository I want to clone)\n> - KeyB (just my personal key with access to my personal stuff)\n> \n> Having both keys in loaded and listed in `ssh-add -L` fails to clone the\n> repository. I tried to change the order of the key in the agent but\n> neither KeyA, KeyB nor KeyB, KeyA will work. The only case that works if\n> I have KeyA loaded an no other key is added to the ssh-agent.\n\nI once had the same problem, due to a server newly closing the connection\ndirectly after the first key failed. Note: the problem was the *server*\n(that was updated at the same time as my local Debian packages).\n\nThe only remedy was to specify the exact key in ~/.ssh/config via\nIdentityFile.\n\nHth,\nJohannes\n"},{"id":"291529","messageId":"7128CED1-381C-4489-A26D-3645D5A7BB69@benle.de","threadId":"42839","inReplyTo":"xmqqziplz63l.fsf@gitster.mtv.corp.google.com","subject":"Re: Multiple Keys in ssh-agent, fail to clone","fromName":"Benjamin Fritsch","fromEmail":"beanie@benle.de","sentAt":"2016-07-15T12:04:59Z","receivedAt":"2016-07-15T12:05:14Z","isPatch":false,"sender":{"key":"beanie@benle.de","avatar":null},"body":"\n> On Jul 13, 2016, at 3:32 PM, Junio C Hamano wrote:\n> \n> Benjamin Fritsch writes:\n> \n>> 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?\n> \n> I do not think this has much to do with the version of Git, unless\n> you are getting an updated SSH client together with your new version\n> of Git from whoever distributes it.\n\nThank you for the great feedback. I could confirm that this is a problem on Bitbucket’s end. Sorry for the confusion.\nI managed to successfully clone with Git 2.9 and Git 2.8\n\nBest,\nben"}]}