SSH error ssh_exchange_identification: read: Connection reset by peer

Question

I am trying to access ssh to a server but got "ssh_exchange_identification: read: Connection reset by peer". The same client works well when I move the computer to home but show the error when the computer is in the work office. Is that possible some LAN network setting in the office network causes the issue? I tried other computers in the office network, the same issue.

Can I change the server settings to fix this issue?

Client and server with the same Debian "Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) x86_64 GNU/Linux"

In the client side, log shows:

OpenSSH_6.7p1 Debian-3, OpenSSL 1.0.1j 15 Oct 2014
debug1: Reading configuration data /home/client/.ssh/config
debug1: /home/client/.ssh/config line 13: Applying options for navtk
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/client/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to www.host.com [xx.xx.xx.xx] port xx.
debug1: Connection established.
debug1: identity file /home/client/.ssh/user type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/client/.ssh/user-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-3
ssh_exchange_identification: read: Connection reset by peer

And the log in server side

Server listening on :: port 443.
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 735
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
debug1: getpeername failed: Transport endpoint is not connected
debug1: get_remote_port failed

Solution 1

"Connection reset by peer" means the TCP stream was abnormally closed from the other end. I think the most likely explanations are that the remote server process handling the connection has crashed, or else some network device (like a stateful firewall or load balancer) has decided to interfere with the connection.

You need to debug this on the remote server if you can. sshd logs through syslog, and on a typical Unix system the log entries will be in one of the files in the /var/log directory. If you're lucky, sshd will be logging something every time it drops your session.

If you have root access on the server, you can run a debugging instance of sshd. Become root and then run:

/path/to/sshd -ddd -p 1022

This will run an instance of the SSH server which will listen on port 1022, accept one connection, and print debugging information to your terminal. Run your client as usual, except specify port 1022 as the port:

ssh -p 1022 user@host

The debugging information printed by the server will hopefully make it clear what is happening.

Edit: The server output indicates that the server isn't crashing or deliberately closing the TCP connection. Something else is causing it to close. I would take a look at any security software installed on the server which might monitor TCP sessions, as well as any firewalls, load balancers, or similar network hardware which might be part of the local network.

Solution 2

"ssh_exchange_identification: read: Connection reset by peer" will also happen when you ended up on the blocklist (e.g. because you entered the wrong password too often). Happened to me with my Synology-NAS. So verify that the IP from which you are connecting isn't on that list.

In the case of a synology, check under "Control panel" / "Security" / "Account".

Solution 3

I am having the same issue. Right now, it looks like the issue is with my ISP. Try doing a traceroute to your server. For me, this fails before reaching the server.

My server is a shared hosting server. My hosting company told me they have had the same issue with other clients using AT&T or Comcast.

I hope this helps, or at least saves you from spending excessive time on other possibilities.

Solution 4

It's too late here, but might be someone just jumping into this find it helpful.

1. Restart (stop & start) the server.
2. Access to server by ssh again with the public ip. (You can continue to next step if it is successfully.)
3. Restart web server.

That's it or you might need to point domain to the public ip again.

My environments are AWS and NGINX.

View more solutions

Comments

[Daniel B]

Using a different port might change the behavior of firewalls, though.

[Tmx]

@Kenster Please check my updates on the question.

[Chloe]

What does the web server have to do with anything?

[Lahiru Jayaratne]

Starting and stopping worked for me as well, AWS instance, nginx server.

[Salem F]

to make life more easy from who comes from google /usr/sbin/sshd -ddd -p 1022

[Admin]

THANK YOU, I've been searching all over for this, specifically issues with Synology - this is the only thing that solved it for me, the source IP sure enough was under the block list!