Git (ssh_exchange_identification) reset connection with peer (windows, gitlab)
I'm trying to connect to a gitlab server (which I don't have) using ssh on Windows (PuTTY). The git clients I've tried have ranged from simple git, git-extensions, sourcetree, and git bash / gui. They all essentially tell me:
Cloning into 'repo'...
debug2: ssh_connect: needpriv 0
debug1: Connecting to git.server [x.y.z.w] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/c/Users/user/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /c/Users/user/.ssh/id_rsa type 1
debug1: identity file /c/Users/user/.ssh/id_rsa-cert type -1
debug1: identity file /c/Users/user/.ssh/id_dsa type -1
debug1: identity file /c/Users/user/.ssh/id_dsa-cert type -1
debug1: identity file /c/Users/user/.ssh/id_ecdsa type -1
debug1: identity file /c/Users/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /c/Users/user/.ssh/id_ed25519 type -1
debug1: identity file /c/Users/user/.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: read: Connection reset by peer
fatal: Could not read from remote repository.
I changed the names repo / server / ip / user, but otherwise this is what I get every time I try to connect. The debug3 posts shouldn't be of interest (?) I've looked at similar posts here and on other ssh and GitLab related parties, but most of them are related to server side issues and installation failures. None of the suggested options had any effect, including key recovery. The version of Gitlab I'm trying to connect with is GitLab 7.7.2 bd98290.
I used putty-gen to convert the private ssh key so that it can be loaded (I tried 3 possible types). I can use ssh on bitbucket and other git servers, so I am puzzled as to why I get dropped every time. Is there a client side I can do to test / debug the connection?
Window
I have a cygwin installation, but I haven't used that in a while. It also links to the standard Windows config files for ssh (which were empty when I first looked at them, I experimented with some additions regarding cyphers and LDAP and various git memory / unpacking options, but none of this really helped)
I disabled Windows Firewall to see if it affected communication, but no luck so far.
Reproducibility
Other people MAY connect to the repository using their SSH keys on the same subnet. I can also use the http version, but it aborts the cloning process by about 88% each time, probably because the repo is (too) large. I wanted to shrink it using reflog, but I would have to clone it locally first, right?
Thanks in advance.
source to share
Here's a solution that ultimately fixed my problem.
1) I noticed that I could not connect using http on the same subnet, but I was able to connect using http from a different subnet.
2) I trimmed all large files with git -ext. It's a really awesome tool for this kind of thing. The only drawback is that it keeps listing large files even when their deletions have been pushed (forcefully) across all branches.
3) For some reason http AND ssh can now connect correctly, even within the same subnet.
Maybe some gitlab networking expert knows what might be causing this? Did I stumble upon some loot? Network glitch? Gitlab slips? Aliens on wires?
source to share