ssh_exchange_identification: read: Connection reset by peer

Question

I am on OS X trying to ssh into a ubuntu 12.04 server. I was able to SSH in -- until abruptly stuff stopped working. I've read online to use the -v to debug this. Output is shown below. If I ssh into a different box and then ssh from that box to the server I am able to login. I have no idea how to debug this problem but would like to learn.

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
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 *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

So far (on advice of message boards) I have looked for a hosts deny file -- but there is no such file on my machine.

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

I have admin access on client machine but not on server.

Answer 1

The abrupt change could be the result of a change in the configuration file on the servers sshd configuration, but you indicate cannot check or alter that without admin right. You can still try the following if the server's admins cannot be reached (in time).

Your log only indicates the local version string, you should check the versions of sshd running on the server and the intermediate machine.

If these versions differ (especially between the local machine and the server and less between the intermediate machine and the server) there might be some negotiation incompatibility, this has happened before in ssh. The solution used to be to shorten the Ciphers, HostKeyAlgorithms and/or MACs entries, either on the commandline (ssh -c aes256-ctr, etc.) or on in your /etc/ssh/ssh_config.

You should look in the debug information (from connecting via the intermediate to the server) for appropriate values as argument for the -c/Ciphers, -o HostKeyAlgorithms/HostKeyAlgorithms and -m/MACs commandline resp. ssh_config changes.

I haven't had this problem myself for a while, but IIRC when I did it was enough to manually force the Ciphers and HostKeyAlgorithms setting, after which I could update the server's sshd version and the problem went away.

Answer 2

You may have been banned by fail2ban or denyhosts. In such a case (and also to check it), if you don't want to bother with your server provider assistance, you need to log into your server from another IP address : e.g. another server, or a friend's home connection, or a wifi hot spot, or using SSH with TOR.

Once logged in, check that your IP address indeed appears in /etc/hosts.deny (on the server side). If so, then fail2ban or denyhosts must be the culprit indeed.

See answers to this question for the procedure to prevent denyhosts to block your address continuously. For fail2ban find your ip with iptables -L --line-number and unban you ip with iptables -D <chain> <chain number>, you check details on howtoforge.

You may want to add your IP address to fail2ban and denyhosts whitelists (respectively /etc/fail2ban/jail.conf, line ignoreip, and /var/lib/denyhosts/allowed-hosts, create it if needed (but beware that the path may be different on your distribution)) to prevent the issue to happen again.

Answer 3

On the host server, remove the ssh pub.key located here: ~/.ssh/authorized_keysfor your mac. Then tail -f /var/log/auth.log while you open another terminal and try to ssh again ssh -v me@server. If you are prompted for a password then there was a problem with your ssh key. If you are still seeing the 'ssh_exchange_identification: read: Connection reset by peer' response, then you should be able to identify what the problem is from the log entry in the '/var/log/auth.log' file after your failed attempt to login.

If you still failed to connect, post the logged entry from the auth file here and I'll revise my answer.

Answer 4

This can happen if you have multiple machines on the network with the same MAC address (for example, if you make a copy of a virtual machine and forget to change the MAC).

Answer 5

Your log means that server-side drops the connection. To find out the reason, you should consult server-side logs, they should show reason for disconnection. You should be almost always be able to find logs in /var/log/messages

I could guess that, as connection dropped just after client sent version number, server somehow threats client as incompatible.

Answer 6

I was faced with the same problem. I would open ssh session successfully but it would get reset after some time. When i tried to connect gain immediately i would get the error "Connection refused". when i debugged the session i got this message at the time when the connection was getting reset

debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1  
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1  
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1                                                           

At this point i realized that there was an IP address conflict on the network. I changed to another address and problem was resolved

Answer 7

I was getting this due to my ISP's nameservers in /etc/resolv.conf. These nameservers are often overloaded and if reverse DNS lookup fails sshd will drop the connection. I solved the problem by using more reliable nameservers, e.g. 8.8.8.8.

Answer 8

Since it hasn't been mentioned explicitly in an Answer, another way this error can appear is if a network-based firewall between you and the server has decided to block the connection. The firewall could have decided that there were "too many" connections from the OS X system's IP, and began blocking it. There were not yet "too many" connections from the other system, and so it was allowed.

The last message you received from the server is one that occurs before you even begin any authentication attempts, which rules out a large class of possibilities surrounding your account, key, or password.

Examples of such brute-force policies from a random sampling of vendors are:

• CloudFlare: How do I use Rate Limiting to protect against brute-force attacks?
• F5: Configuring brute force attack protection
• FortiNet: creating custom IPS signature to detect a pattern rate - example to detect a Brute-force attack
• Palo Alto: Prevent Brute Force Attacks
• Sonicwall: How to block Brute Force and Dictionary attacks with SRA

Answer 9

I had the same problem but it turned out the cause was different: I was using wrong port.

On newer versions of ssh the error given is Connection refused or Bad port.

On older versions the error given is ssh_exchange_identification: read: Connection reset by peer

So when you get such error check if port is correct.

Answer 10

I know this question is old, but I wanted to share some findings I had. Check if /var/empty/sshd on the server has appropriate ownership and permissions.

We had a chef script that was modified to update some directory permissions, but inadvertently updated the directory below the intended target, changing ownership of /var to an application user/group and changing the permissions to 775.

Answer 11

I ran into this exact error when trying to connect to all my remote hosts via the Wi-Fi bridge option on my Android device (Huawei P30 Pro). When I used the USB tethering option to share the same Internet connection, no problem.

Absolutely nothing else changed in the SSH configuration or options on the client or servers.

TL;DR: sometimes, nothing you can do.

Answer 12

In my case it was a different IP address prefix length. The server had set 192.168.0.2/24 while client was 192.168.1.1/23. There was no connectivity issues whatsoever (for example cups printing works) until I tried to ssh.

Check ip addr show on both sides.