bibucket ssh_exchange_identification: read: Connec

问题:

I'm trying to setup a passwordless git connection to bitbucket. I'm using git bash on Windows Server 2008.

Cloning over HTTPS works fine:

nskoric@P8-DEV /z/test
$ git clone https://[e-mail]/nek-plan/gittest.git
Cloning into 'gittest'...
Password for 'https://[e-mail]':
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
Checking connectivity... done.

But, HTTPS is not acceptable because I need passwordless login. So I generated a private/public key pair, uploaded public key to bitbucket and set up Host/IdentitiyFile in .ssh/config. Then I tried connecting and failed.

Port 22 is closed on my company firewall:

nskoric@P8-DEV /z/test
$ ssh [e-mail] -vv
OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014
debug1: Reading configuration data /u/.ssh/config
debug1: /u/.ssh/config line 1: Applying options for *bitbucket.org
debug2: ssh_connect: needpriv 0
debug1: Connecting to bitbucket.org [131.103.20.168] port 22.

So, I'm using port 443, as per bitbucket documentation:

nskoric@P8-DEV /z/test
$ git clone ssh://[e-mail]:443/nek-plan/gittest.git
Cloning into 'gittest'...
ssh_exchange_identification: read: Connection reset by peer
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I tried googling "bitbucket ssh_exchange_identification: read: Connection reset by peer", but it didn't help :-/ Then I tried debugging SSH connection, but this is farthest I got:

nskoric@P8-DEV /z/test
$ ssh [e-mail] -p 443 -vv
OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014
debug1: Reading configuration data /u/.ssh/config
debug1: /u/.ssh/config line 1: Applying options for *bitbucket.org
debug2: ssh_connect: needpriv 0
debug1: Connecting to altssh.bitbucket.org [131.103.20.174] port 443.
debug1: Connection established.
debug1: identity file /u/.ssh/bitbucketnek type 1
debug1: identity file /u/.ssh/bitbucketnek-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

So, SSH found the right identity file (/u/.ssh/bitbucketnek) and then died. Now, it would be really helpful if I could figure out if the problem is in my "bitbucketnek" private key, or is the problem in our company firewall, or something third. Any ideas?

Thanks!

回答1:

As a helpful annotation, I had this case in a shared hosting environment, specifically GoDaddy, and the reason It gave me this error:

ssh_exchange_identification: read: Connection reset by peer

Solution: my local machine's ip had been blocked by GoDaddy, so I had to contact their support, send them a screenshot of the error output from running:

ssh -v user@domain

, and also provide them with my ip. They noticed my ip had been in fact blocked, removed it, and problem solved.

回答2:

ssh_exchange_identification: read: Connection reset by peer

"Connection reset by peer" means the TCP connection was "abnormally closed" from the remote (server) side. "ssh_exchange_identification" means that it's happening during a phase where the client and server exchange software version strings. This happens before the client and server exchange host keys or try to authenticate. In other words, the remote end of the connection is dropping before any kind of key exchange or authentication has taken place.

An abnormal close (connection reset) typically indicates that the server process exited without closing the connection, or it crashed, or that something like a firewall or load balancer is interfering with the connection. Normally I'd suggest to troubleshoot this on the server. But given this is bitbucket, it's probably safe to start with the assumption that their servers are working correctly. The likely alternative is that your traffic is going through a stateful firewall, or a load balancer, or a similar device within your network, and it's forcing the TCP stream closed for some reason.

I see you're trying to run SSH on port 443, probably following these instructions. Maybe your network engineers have blocked port 22 to the Internet? Maybe they're also doing packet inspection on port 443, and they're blocking traffic which doesn't look like HTTPS (HTTP over SSL).

回答3:

I've seen this happen when I tried to pull updates on 20 or so projects, via a script, one immediately after another. I suspect I ran into some kind of limit. Adding a 'sleep 10' after each pull seems to have solved the problem.