9

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
4
  • 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. Dec 20, 2013 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, 2013 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, 2013 at 9:29
  • Refer to new edit on post.
    – Dylan
    Dec 20, 2013 at 9:34

7 Answers 7

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 [email protected]
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
1
  • Thanks! Changing the owner of /var/empty fixed the issue for me. Sep 18, 2018 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.

1

It is certainly a bug, ssh works with one of my machines but not the other. I solved it, follow these.

  1. Generate an access token with never expire date, and select all the options available.
  2. Remove the existing SSH keys.
  3. Clone the repo with the https instead of ssh.
  4. Use the username but use the generated access token instead of password.

enter image description here

alternatively you can set remote to http by using this command in the existing repo, and use this command git remote set-url origin https://gitlab.com/[username]/[repo-name].git

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"

3
  • 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, 2017 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.
    – Allison
    Feb 28, 2017 at 18:58
  • This worked once. restarted the computer, can no longer ssh into the mac... Why are these problems so mysterious on Mac?
    – airtonix
    May 12, 2023 at 3:06
-1

If you are using a private key or a security key to login to your server then you need to change the permission for the key file to 660, using command

sudo chmod 660 File_Name

1
  • 1
    (1) While this can be the cause of ssh not working, it’s not clear how this problem would randomly inflict a working system.  (2) This answer, such as it is, would be more useful it you identified the file you’re talking about, or provided instructions to allow a user to identify it.  (3) I guess you’re talking about a file in (under) the user’s home directory.  If that’s the case, sudo should not be necessary. May 24, 2019 at 3:08

You must log in to answer this question.

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