agent forwarding fails on update from Git-1.9.4-preview20140611 to Git-1.9.4-preview20140815

[brendandc]

I use agent forwarding, and connections my AWS servers bounce through an intermediate server.

Basically, the setup works in Git-1.9.4-preview20140611 but as soon as I install Git-1.9.4-preview20140815. Note: it also fails on the latest version: Git-1.9.4-preview20140929.

I am using Windows7, not sure if there any any other relevant details, but I am happy to provide them.

Providing my .ssh/config file with changed server names to help clarify the situation.

User brendandc

ForwardAgent yes

Host intermediary
      HostName intermediary.example.org

Host *.example.org
     ProxyCommand ssh intermediary nc %h %p

And then I connect in the git bash terminal with: ssh server-1.example.org

[dscho]

Try ssh -v -v -v -v -v -v server-1.example.org. Hopefully the superverbose log will provide you with enough clues.

[linquize]

what option it is! 6x -v arguments

[brendandc]

Here is the output I get:

OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014
debug1: Reading configuration data /c/Users/Brendan/.ssh/config
debug1: /c/Users/Brendan/.ssh/config line 8: Applying options for *.example.org
debug1: Executing proxy command: exec ssh intermediary nc server-1.example.org 22
debug1: permanently_drop_suid: 500
debug3: Incorrect RSA1 identifier
debug3: Could not load "/c/Users/Brendan/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /c/Users/Brendan/.ssh/id_rsa type 1
debug1: identity file /c/Users/Brendan/.ssh/id_rsa-cert type -1
debug1: identity file /c/Users/Brendan/.ssh/id_dsa type -1
debug1: identity file /c/Users/Brendan/.ssh/id_dsa-cert type -1
debug1: identity file /c/Users/Brendan/.ssh/id_ecdsa type -1
debug1: identity file /c/Users/Brendan/.ssh/id_ecdsa-cert type -1
debug1: identity file /c/Users/Brendan/.ssh/id_ed25519 type -1
debug1: identity file /c/Users/Brendan/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
ssh_exchange_identification: Connection closed by remote hostssh_exchange_identification: Connection closed by
 remote hostssh_exchange_identification: Connection closed by remote hostssh_exchange_identification: Connecti
on closed by remote hostssh_exchange_identification: Connection closed by remote hostssh_exchange_identificati
on: Connection closed by remote hostssh_exchange_identification: Connection closed by remote hostssh_exchange_
identification: Connection closed by remote host

The other interesting piece of information from that trace is that the longer I wait to hit ctrl-c and break out, the more Connection closed by remote hostssh_exchange_identification: I get.

Wasn't able to figure it out after searching a bit, primarily focusing on the debug3 statements. The only other relevant piece of information I can think of is the result of openssl version -v on the intermediary server, which is: OpenSSL 1.0.1 14 Mar 2012

I can provide the "good" output where the connection succeeds on Git-1.9.4-preview20140611, just let me know if it would be useful.

[dscho]

I can provide the "good" output where the connection succeeds on Git-1.9.4-preview20140611, just let me know if it would be useful.

Well, my idea was more to help you identify the problem yourself.

Maybe my following observations will help you with that:

1. the debug3 statement seems to suggest that there is a misconfiguration which asks ssh to load a private key as if it were a public key
2. the only key that has a valid type (i.e. not type -1) is id_rsa. If your intermediary host has stored an authorized_key corresponding to any of the other private keys, that will be the explanation why it fails. In that case, I would suspect an ssh in the current Git for Windows lacking support for DSA.
3. OpenSSH and OpenSSL are independent projects, i.e. OpenSSH does not use OpenSSL at all, therefore it will not help your investigation to look at OpenSSL.
4. If you redirect the output of both the working and the non-working scenario into files (e.g. ssh ... 2>&1 | tee working.txt), you should be able to see the differences very easily using git diff --no-index working.txt non-working.txt.
5. It might make more sense to look at the Git for Windows SDK, the designated successor for the environment to develop Git for Windows prior to version 2. Please note that you will need to use a snapshot installer for the moment because the SDK is under heavy development right now.

[dscho]

I'll just assume that switching to Git for Windows 2.x solved the problem.