I'm not using hosts.allow or hosts.deny, furthermore SSH works from my windows-machine (same laptop, different hard drive) but not my Linux machine.

ssh -vvv root@host -p port gives:

OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [host] port <port>.
debug1: Connection established.
debug1: identity file /home/torxed/.ssh/id_dsa type -1
debug1: identity file /home/torxed/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
ssh_exchange_identification: read: Connection reset by peer

On the windows machine, everything works fine, so I checked the security logs and the lines in there are identical, the server treats the two different "machines" no different and they are both allowed via public-key authentication.

So that leads to the conclusion that this must be an issue with my local ArchLinux laptop.. but what?

[torxed@archie ~]$ cat .ssh/known_hosts 
[torxed@archie ~]$ 

So that's not the problem...

[torxed@archie ~]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

No conflicts with the firewall settings (for now)..

[torxed@archie ~]$ ls -la .ssh/
total 20
drwx------  2 torxed users 4096 Sep  3  2013 .
drwx------ 51 torxed users 4096 May 11 11:11 ..
-rw-------  1 torxed users 1679 Sep  3  2013 id_rsa
-rw-r--r--  1 torxed users  403 Sep  3  2013 id_rsa.pub
-rw-r--r--  1 torxed users  170 May 11 11:21 known_hosts

Permissions appear to be fine (same on the server).. Also tried without configuring /etc/ssh/ssh_config with the same result except for a lot of auto-configuration going on in the client which ends up with the same error.

  • 1
    please give the output of iptables-save|grep -v '^#', that'll include the other tables (e.g. nat and mangle). If they're empty, simply state that. Your iptables output above is by default limited to the filter table. Also, on the SSH server run SSH on an alternative port like this and give the debug output. Commented May 11, 2014 at 12:38
  • @0xC0000022L gist.github.com/Torxed/d7a5a556c527ffbb609d and gist.github.com/Torxed/1fd9b5b0c276629caf30 and regarding the firewall, SSH is working for my windows drive (again, same laptop ergo mac and IP) but not for my linux disk.
    – Torxed
    Commented May 11, 2014 at 13:07
  • two more things. You need to connect to the instance on the alternative port. Otherwise you won't be able to see possible problems. Concernings the Windows vs. Linux thing, is one of them using IPv6 perhaps (ip6tables-save)? Commented May 11, 2014 at 13:19
  • @0xC0000022L I'm extremely sorry. I connected to the wrong IP.. Running SSH on port 8080 that's why i recieved this issue when connecting to a host running a web-cache on port 8080 >_<
    – Torxed
    Commented May 11, 2014 at 13:21
  • 1
    This happened to me intermittently while my server was being hit by some random attacker trying to brute-force sshd. Fixed by adding firewall rules to drop connections from the attacker. Commented Dec 16, 2014 at 0:22

13 Answers 13


Originally posted on Ask Ubuntu

If you have ruled out any "external" factors, the following set of steps usually helps to narrow it down. So while this doesn't directly answer your question, it may help tracking down the error cause.

Troubleshooting sshd

What I find generally very useful in any such cases is to start sshd without letting it daemonize. The problem in my case was that neither syslog nor auth.log showed anything meaningful.

When I started it from the terminal I got:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Much better! This error message allowed me to see what's wrong and fix it. Neither of the log files contained this output.

NB: at least on Ubuntu the $(which sshd) is the best method to satisfy sshd requirement of an absolute path. Otherwise you'll get the following error: sshd re-exec requires execution with an absolute path. The -p 10222 makes sshd listen on that alternative port, overriding the configuration file - this is so that it doesn't clash with potentially running sshd instances. Make sure to choose a free port here.

Finally: connect to the alternative port (ssh -p 10222 user@server).

This method has helped me many many times in finding issues, be it authentication issues or other types. To get really verbose output to stdout, use $(which sshd) -Ddddp 10222 (note the added dd to increase verbosity). For more debugging goodness check man sshd.

The main advantage of this method is that it allows you to check the sshd configuration without having to restart the sshd on the default port. Normally this should not interfere with existing SSH-connections, but I've seen it. So this allows one to validate the configuration file prior to - potentially - cutting off ones access to a remote server (for example I have that for some VPS and even for physical servers where I need to pay extra to get out-of-band access to the machine).

  • I connected to the wrong IP, but this got me going.. Noted that none of my connection attempts showed up in the debug output..
    – Torxed
    Commented May 11, 2014 at 13:39
  • 4
    $(which sshd) -Ddp 10222 let me finally see what was causing my issue. Thanks a bunch!
    – Cuga
    Commented Feb 17, 2015 at 16:40
  • 1
    For reverse SSH shell with dropbear on OpenWRT, it can be, that dropbear isn't actually listening on the right interface/ localhost. ps | grep drop and look for -p <PORT> or the right IP and localhost accordingly. Use netstat -nt to look for active SSH connections, there you can find the source IP/ interface.
    – AdamKalisz
    Commented Jul 8, 2020 at 10:48

You can also have a host who's memory is so badly fragmented that it can't allocate a page a contiguous memory to fork the process for hosting an SSH session.

In such a case, you can get either of the messages:

ssh_exchange_identification: read: Connection reset by peer


Connection closed by aaa.bbb.ccc.ddd

depending on how far the host gets before it bails out.

If memory fragmenting is the apparent cause, the solution is to access the server via other means and to restart some of the pertinent services. I have found Apache and MySQL to be the culprit on VM's since VM's don't have a swap partition. Failing that, reboot the host.


Just in case, because this happened to me. Get sure you have sshd running in the host!

It's a stupid failure, but might be really be your problem.

  • 12
    If sshd was not running the connection would not be closed but refused (try ssh -p someportwithoutsshd localhost).
    – Anthon
    Commented Oct 29, 2014 at 9:08
  • 5
    Well, my case wasn't a direct connection. I created a Reverse Tunnel, to a non-listening machine, and that was the output in the ssh client connection.
    – txomon
    Commented Oct 29, 2014 at 14:17
  • 1
    stupid me also don't know that I don't have any sshd running, fixed it by installing openssh-server Commented May 3, 2018 at 2:00

I found that this error was due to the exceeded the ssh sessions to the server. I found the hosts trying to connect and killed all sessions from all clients. The issue solved after clearing up all sessions.

  • 25
    How did you do that?
    – aborted
    Commented Oct 23, 2015 at 14:46
  • 5
    how did you do that? ping...
    – knocte
    Commented Jul 25, 2016 at 7:21
  • One way would be finding the open sessions using who and killing the user processes.
    – Bent
    Commented May 22, 2017 at 6:34
  • 1
    How to kill ssh sessions : unix.stackexchange.com/questions/127571/…
    – Tejas Kale
    Commented Jul 4, 2018 at 11:14

I ran across the ssh_exchange_identification: read: Connection reset by peer problem in a script that starts 16 or more ssh sessions in a loop. sshd apparently can't keep up; adding a short sleep (clearly a workaround ... :D downvoters) solved my problem:

for i in $(seq 32)
    ssh -f root@$HOST "./test_server -p $(expr $BASE_PORT + $i)" > svr${i}.out
    # for > 8 connections, ssh has ssh_exchange_identification issues
    sleep 0.1

Or you might have done what I did, last night, and deleted /var/empty. Apparently that directory and its permissions are essential to the functioning of sshd and it won't remake the directory when restarted /etc/init.d/sshd will fail to restart and nothing systemd will tell you why.

I found the issue by running sshd in the foreground:

# /usr/sbin/sshd -Dd
  Missing privilege separation directory: /var/empty/sshd

Rebuilding the directories solved the issue in my case:

drwxr-xr-x. root root  /var/empty
drwx--x--x. root root  /var/empty/sshd

Note to Linux programmers: Critically important stuff in /var/empty ... really???

  • ls -ld /var/emptyls: cannot access '/var/empty': No such file or directory. So at least one distribution has done away with this entirely. Looking at the /etc/init.d/sshd script, it seems that on Debian, at least, the privilege separation directory is now /var/run/sshd and is created at start-up time if it doesn't already exist. Commented Sep 9, 2017 at 21:21

I got the error ssh_exchange_identification: Connection closed by remote host when trying to connect to SSH: I did a remote port forwarding for the SSH port 22 of my local computer so I can access it temporarily from a remote server on Internet.

In fact the error was just displayed because I did not remember that I disabled the SSH service on startup so I had to start the SSH service on my local computer: sudo service ssh start.


First thing first; telnet to the host IP address to verify if the port 22 is actually listening (opened) on that host:

telnet x.x.x.x 22

(if not, then you may hook up a console cable to login)

In my case, it was not working and I hooked up a console cable to login. Once I logged in, I discovered that all 5 VTY lines were busy on that host (a Cisco router).

I cleared old connections that were hanging there to free up the VTY lines, it worked. I added the command "exec-timeout 15" under the VTY lines. Then I removed the console cable.


Make sure to set a 5-10 minutes timeout on all your devices - (if no activity is detected).

  • 2
    In that case, you’d get a “connection refused” like another answer implied, not “Connection establishes” followed by “Connection reset by peer”
    – Jeff Schaller
    Commented Nov 3, 2017 at 10:25
  • 1
    Having telnet available (daemon listening for telnet) is a pretty severe security flaw, a flaw that is the primary reason ssh is the preferred remote console.
    – Jeter-work
    Commented Dec 5, 2017 at 14:34
  • 2
    Using the telnet client to probe the ssh daemon at port 22 is not a security flaw. Using the telnet client to connect to the telnet daemon at port 23 is a security flaw. Commented Jul 26, 2019 at 21:42

I was getting similar error while trying to ssh with root user, into a recently created container:

ssh root@localhost -p 8022  
  ssh_exchange_identification: Connection closed by remote host

# local port 8022 is redirected to container ssh port 22

Apparently, it happened since the user ("root" in my case) did not have a password.

Once I added user's password, and restarted sshd (inside the container):

echo 'root:<PASSWORD>' | sudo chpasswd
sudo service ssh restart

Then I could ssh into the container.


If you're in an environment where an intermediate piece of hardware, say a bastion, relays your SSH, then it might be descriptive of the fact that the bastion hung up because it couldn't reach the remote host. Naturally they wouldn't want to display this information and let you attempt to discover remote hosts.


The error ssh_exchange_identification: Connection closed by remote host can happen for some unknown reasons. When i was using Visual Studio code. The same error happened when i tried to pull from remote repo using git pull command.

I just closed the embedded terminal and opened Ubuntu's terminal and pulled again. And it was successful

Mostly, restarting the system will solve the problem

  • Happened to me for unknown reasons as well! I was primariliy using VSCode, but I wasn't able to SSH through powershell in general (WIndows 10). Restarted my PC and it starts working again.
    – aIKid
    Commented May 8, 2021 at 10:40

My case was mistakenly set socket proxy (which is not working). I got exactly same ssh -vvv output and empty sshd log.


From with CentOS Linux release 7.4.1708 (Core) with OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017 behind a connection not filtering ports I had:

ssh_exchange_identification: Connection closed by remote host

And it turned out that my Raspberry Pi was off !

I was thinking that a host not powered on would have yield the error "No route to host". The Raspberry Pi is behind my ISP router so it is probably it that was closing the connection.

Then I repeated the experiment (attempting connection to a powered off Raspberry Pi) from another internet connection also not filtering ports with Debian Stretch with OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017 and this time I had the expected:

No route to host

You must log in to answer this question.

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