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
-vto 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.
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.
The abrupt change could be the result of a change in the configuration file on the servers
sshdconfiguration, 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
sshdrunning 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
You should look in the debug information (from connecting via the intermediate to the server) for appropriate values as argument for the
MACscommandline 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
sshdversion 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.
You may have been banned by
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
denyhostsmust be the culprit indeed.
See answers to this question for the procedure to prevent
denyhoststo block your address continuously. For
fail2banfind your ip with
iptables -L --line-numberand unban you ip with
iptables -D <chain> <chain number>, you check details on howtoforge.
You may want to add your IP address to
/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.logwhile 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.
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
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:
- 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
I had the same problem but it turned out the cause was different: I was using wrong port.
On newer versions of
sshthe error given is
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/sshdon 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.