8

I have been connecting to a remote server through my Mac for about a month now. As of recent though, I tried to connect using ssh dylan@MY_IP and got this message.

ssh_exchange_identification: read: Connection reset by peer

I also got some diagnostic information...

debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to {MY IP{ [MY IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/id_rsa type -1
debug1: identity file /Users/watson/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/watson/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /Users/watson/.ssh/id_dsa type 2
debug1: identity file /Users/watson/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2

After doing some research, I tried the following...

  1. Restarted my router
  2. Cleared my "known_hosts" file
  3. Deleted my "known_hosts" file
  4. Released & Renewed my DHCP
  5. I've also tried from another device (Windows) using Putty with an error as well

Note that I haven't made any changes to the server to inhibit this communication.

Also, I'm not sure if this would cause issues, but I have connected to it by it's domain name as well as it's IP.

In addition, I was able to successfully connect from another IP address.

I know this is a large issue with many resources out there, but a lot of the solutions did not work nor did I really see any type of resolution for anyone.

Update

I forced it to protocol 1. Instead of "Connection reset by peer", I now get "Connection closed by remote host". Running it with debug information revealed:

debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to MY_IP [MY_IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/identity type -1
debug1: identity file /Users/watson/.ssh/identity-cert type -1
ssh_exchange_identification: Connection closed by remote host
  • Do you use public-key authentication? Do you have any key in /Users/watson/.ssh/id_dsa? Try to backup the file and remove it. – pabouk Dec 20 '13 at 8:39
  • I do no use public-key authentication; however, there is a single key in the file. I tried removing the file, but there was no change is running the command. – Dylan Dec 20 '13 at 9:25
  • if it is a problem with protocol version you could force to connect with protocol version 1 with ssh -1 ... – wkaha Dec 20 '13 at 9:29
  • Refer to new edit on post. – Dylan Dec 20 '13 at 9:34
4

This is how I solved the "ssh_exchange_identification: Connection closed by remote host" error when connecting to an SSH server.

I got this error when trying to connect to an embedded Linux machine, after unpacking a package to root. Lots of library files were replaced, including libssl.

Trying to connect:

chetic@ubuntu:~$ ssh -v root@192.168.1.100
OpenSSH_6.2p2 Ubuntu-6ubuntu0.3, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to SC [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/delaval/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/delaval/.ssh/id_rsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_dsa type -1
debug1: identity file /home/delaval/.ssh/id_dsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.3
ssh_exchange_identification: read: Connection reset by peer

Googling only seemed to suggest checking hosts.deny and hosts.allow, but my target machine had no such files.

After a reboot (as per Karthik's suggestion) sshd was not running. I tried manually starting sshd on target:

# sshd
OpenSSL version mismatch. Built against 1000002f, you have 1000105f

I replaced /usr/lib/libssl.a with the original version and started sshd and things were back to normal. The problem was in my case caused by an incorrect version in the package I originally unpacked to root.

3

I was getting the same error (but from any machine, including the troublesome machine via ssh localhost).

It started when I migrated a users profile; i.e. after copying files as root, then did commands like chown -R username /Users/username/Destop

anyway, totally unsure why /var/empty owner was changed to username, but ssh definitely needs /var/empty to be owned by root (otherwise you get ssh_exchange_identification: read: Connection reset by peer):

    sudo chown root /var/empty
  • Thanks! Changing the owner of /var/empty fixed the issue for me. – Yevhen Pavliuk Sep 18 '18 at 8:33
1

This isn't a problem with your local machine, but a problem on the server side. There could be multiple factors causing this problem:

  1. Changes in the /etc/hosts.allow or /etc/hosts.deny configuration on the remote server.
  2. Heavy server load.

In the past, when I've had these problems, I've done one of two things, in the following order:

  1. Modify the /etc/hosts.allow as referenced in the above article. (and restart the SSH server)
  2. If /etc/hosts.allow is already the way it is required to be, just restart the SSH server (and be careful when you're doing this!)
  3. If the restart doesn't work, regenerate the server keys and restart the SSH server (this is risky, since every user logging in to this machine will get a error about the server having keys changed)

More often than not, 1 solves the problem, but I've had to do 2 in some cases.. I haven't been able to figure out why that is the case, only that it has worked. Perhaps it has something to do with the way the key is presented, or perhaps it got corrupted in some way - I am not sure. But what I do know is the error is entirely something to do with the server, and the way the handshake happens when the SSH connection is being set uo.

1

I had SSH set up with Cygwin and in my case it was the Windows firewall that caused exactly this error, so make sure to allow connections to port 22.

0

I managed to solve this issue myself really easily.

In normal OS X you can solve this by simply toggling "Remote Login" in System Preferences/Sharing.

However, if it's a headless server (like in my case) you can use OSX Server app to go to (you server name)/Settings and toggle "Secure shell connections on and off again"

  • 1
    I noted as well that how you can work around the problem, but it doesn't fix it: disabling remote login severely affects the system, and having to toggle remote login every time one wants to ssh to some specific place is not a viable solution. – Ant6n Feb 27 '17 at 18:20
  • Yeah this is still a horrible issue I have. I've just made a root cron script which restarts the service every midnight. – Sirens Feb 28 '17 at 18:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.