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.
    – phemmer
    Aug 24, 2014 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, 2014 at 4:36
  • 14
    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, 2014 at 5:07
  • did you find a solution to it? what was the problem?
    – MeV
    Aug 7, 2015 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. Mar 13, 2016 at 21:49

12 Answers 12


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.

  • 3
    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, 2014 at 9:40
  • 3
    @chakrit how did you clean out your old ssh configuration files?
    – Jonathan
    Jan 7, 2017 at 15:12
  • @Jonathan I mounted a recovery disk to do it.
    – chakrit
    Jan 10, 2017 at 6:53
  • @chakrit: if you could share what exact settings had changed, that would be really useful. Nov 25, 2019 at 6:28

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 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. Nov 29, 2017 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).


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


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.


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.


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

Check ip addr show on both sides.

You must log in to answer this question.

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