ssh_exchange_identification: read: Connection reset by peer

  • 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 [email protected]
    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.

    I would recommend starting an `sshd` listening on an alternate port, with verbose output, and providing the output when trying to connect to it. `$(which sshd) -d -p 23`. If you don't have the ability to do this, your options are pretty limited. Best bet is to get someone who has admin rights on the server.

    Could it be that the administrator on the server restricted your access for some reason? In any event, I might contact that person.

    The hosts.deny and hosts.allow file should be checked on the **server**, not on the client. Also, the system logs on the _server_ should be checked. If you don't have access to those either, you may want to contact the server admin to take a look.

    did you find a solution to it? what was the problem?

    Was a hosts.deny list that was filled by the admin with an automatic script. As I forgot my password at some point, I had a few unsuccessful attempts of logging in, which is when my IP was put on the hosts.deny list. So much for the productivity of overzealous security.

    You might also want to check if your server is not out of memory.

    When I got that error message from the client yesterday, the problem was an issue on the server that showed up as "read-only filesystem" errors, which we resolved by rebooting the server.

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

    In my case, the server `sshd` package was updated to a newer version and result in the incompatibility with my current `ssh` client configuration as you said. Clearing out my old `ssh` configuration files did the trick. This should be the accepted answer.

    @chakrit how did you clean out your old ssh configuration files?

    @Jonathan I mounted a recovery disk to do it.

    @chakrit: if you could share what exact settings had changed, that would be really useful.

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

  • 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 [email protected]. 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.

    No need to delete SSH key in some cases. Go straight to tail -f /var/log/auth.log and check recent attempts.

  • 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).

  • 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

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

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

  • 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:

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

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

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM