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
  • The server is deciding to drop the connection immediately after you connect. There are several reasons this could be happening. You'll need to troubleshoot this on the server side.
    – Kenster
    Dec 26, 2014 at 13:31
  • @Kenster. Thanks! How can I get more logs from server side? And if it if on the server side why the same settings works well for the client at home? Will router firewall settings also affect this?
    – Tmx
    Dec 26, 2014 at 19:34

6 Answers 6


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

  • Using a different port might change the behavior of firewalls, though.
    – Daniel B
    Dec 26, 2014 at 22:36
  • @Kenster Please check my updates on the question.
    – Tmx
    Dec 27, 2014 at 5:50
  • to make life more easy from who comes from google /usr/sbin/sshd -ddd -p 1022
    – Salem F
    Apr 16, 2020 at 9:58

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

  • 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!
    – Othyn
    Jul 2, 2022 at 15:37

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.


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.

  • What does the web server have to do with anything?
    – Chloe
    Mar 30, 2018 at 1:37
  • 1
    Starting and stopping worked for me as well, AWS instance, nginx server. May 23, 2019 at 9:01

There may be many reasons but one of most possible reason can be(in my case it was) ssh / port 22 is not allowed by firewall.

You can allow ssh connection by User-interface (some providers allow that) or If you have any alternative method to login (Ex. digitalocean provide a console button ) you can run below command

sudo ufw allow ssh
sudo ufw allow 22

this may be way too late but it could save someone's day some day. Well, had same issue I added ssh:my.ip.address in the /etc/hosts.allow file and restarted the server.

Ps: this works if you can access the server in someother way.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .