Reputation: 2060
I'm trying to connect to a gitlab server (which I don't have the authority over) using ssh on Windows (PuTTY). The git clients I have tried range from simple git, git-extensions, sourcetree and git bash/gui. All of them 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've changed the names of the repo/server/ip/user but otherwise this is what I get every time I try to connect. The debug3 messages should not really be of any interest(?) I've looked at similar posts here & on other sides related to ssh and GitLab, but most of them involve server-side issues and installation snags. None of the suggested options have had any effect at all, including regenerating the keys. The Gitlab version I'm trying to connect to is GitLab 7.7.2 bd98290.
I used putty-gen to convert the private ssh key so that it could be loaded ( I tried the 3 possible types). I can use ssh on bitbucket and other git servers, so I'm puzzled why I get thrown off every time. Is there a client-side thing I can do to verify/debug the connection?
Windows
I do have a cygwin install, but haven't used that in a while. It also links back to the standard windows config files for ssh (which were empty when I first looked at them, I've experimented with some additions regarding cyphers and LDAP and various git memory pack/unpack settings, but none of that really helped)
I have turned off windows firewall to see if that had any effect on the communication, but no luck so far.
Reproducibility
Other people CAN connect to the repository with their SSH keys, in the same subnet. I can also use the http version, but it breaks the clone process at around 88% every time, probably because the repo is (too) big. I wanted to downsize it using reflog, but I'd have to be able to clone it locally first, right?
Thanks in advance.
Upvotes: 5
Views: 7378
Reputation: 2060
Here's the solution that eventually fixed my problem.
1) I noticed I could not connect using http within the same subnet, but I managed to connect using http from another subnet.
2) I trimmed all the large files using git-ext. This is really an awesome tool for this kind of thing. The only downside is that it keeps listing the big files, even when their deletes have been pushed (forced) on all branches.
3) For some reason, the http AND ssh now manage to connect correctly, even within the same subnet.
Maybe some of the network gitlab specialist know what may have caused this? I bumped into a treshold of some kind? Network glitch? Gitlab slip up? Aliens on the wires?
Upvotes: 1