Linux – SSH error ssh_exchange_identification: read: Connection reset by peer

debianlinuxnetworkingsshvpn

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

Best Answer

"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.

Related Question