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.

  • 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. – Patrick Aug 24 '14 at 4:26
  • Could it be that the administrator on the server restricted your access for some reason? In any event, I might contact that person. – mdpc Aug 24 '14 at 4:36
  • 11
    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. – ckujau Aug 24 '14 at 5:07
  • did you find a solution to it? what was the problem? – MeV Aug 7 '15 at 8:40
  • 2
    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. – K.-Michael Aye Mar 13 '16 at 21:49

10 Answers 10

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.

  • 2
    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 Sep 27 '14 at 9:40
  • 1
    @chakrit how did you clean out your old ssh configuration files? – Jonathan Jan 7 '17 at 15:12
  • @Jonathan I mounted a recovery disk to do it. – chakrit Jan 10 '17 at 6:53

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.

  • This fixed my issue. Thanks! – Amudhan May 11 '17 at 6:38
  • Fixed mine as well, thanks – cutrightjm May 11 '17 at 17:30

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.

  • No need to delete SSH key in some cases. Go straight to tail -f /var/log/auth.log and check recent attempts. – Jack Robson Nov 29 '17 at 13:58

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

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 keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com 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

  • Downvotes, what's wrong with the answer? It can still be a valid case to check when going down a list, just maybe not a common one among others. – Pysis Sep 24 '16 at 2:15
  • @Pysis: Correct, upvoted answer – Daniel Nov 24 '16 at 22:42

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.

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.

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.

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:

protected by Community Jul 9 '15 at 19:45

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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