I can connect from every other computer on the LAN, as well as externally. It connects fine to other machines running SSHD. When trying ssh with verbosity, I get the following readout:

$ ssh -vvv
OpenSSH_6.2p2, OpenSSL 1.0.1e 11 Feb 2013
debug2: ssh_connect: needpriv 0
debug1: Connecting to [] port 22.
debug1: Connection established.
debug1: identity file /home/Steven/.ssh/id_rsa type -1
debug1: identity file /home/Steven/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/Steven/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /home/Steven/.ssh/id_dsa type 2
debug1: identity file /home/Steven/.ssh/id_dsa-cert type -1
debug1: identity file /home/Steven/.ssh/id_ecdsa type -1
debug1: identity file /home/Steven/.ssh/id_ecdsa-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

Any idea what I might have messed up? I don't recall changing in the SSH config files, only adding some users to groups to experiment with permissions. Even when I try not specifying an account (as above) it still hangs at "Local version string SSH-2.0-OpenSSH_6.2" for a minute before giving the final error. I'm running Ubuntu Server 12.04 x86, for what it's worth.

  • 1
    Have you tried specifying /dev/null as the identity file? – Ignacio Vazquez-Abrams Jul 9 '13 at 3:38
  • 1
    have you checked ssh related logs in remote server i.e ? – Rahul Patil Jul 9 '13 at 4:36
  • 1
    Looks like a network problem. You could run tcpdump -i eth0 -n host and tcp port 22. You also may try ssh-agent and ssh-add /home/Steven/.ssh/id_dsa – Hauke Laging Jul 9 '13 at 4:42
  • Take a look at some of the solutions in this SU Q&A: superuser.com/questions/568891/… – slm Jul 9 '13 at 6:02
  • What are the changes you made, before this issue ? – Rahul Patil Jul 9 '13 at 6:55

What this means, ultimately, is that the SSH server on the other end has crashed or is in some way not working. It's still listening on the socket but it's not capable of performing a cryptographic handshake.

The only solution is to restart the process on the remote side.


I had this very same problem, what i found was my IP keept getting added to the etc/hosts.deny file.

I resolved this by simply logging into another VPS server then connecting ssh into the blocked VPS and removed my (home static) IP from the hosts.deny file.


My First attempt was to find "ssh_exchange_identification: read: Connection reset by peer", and cross check with source code , but unfortunately I haven't found any. So with several method I tried to replicate same problem in my side , but unable to create same issue in my side, as you can see as below.

With sshd_config DenyUsers root

Client Side log

Permission denied, please try again

Server Side log

Jul 2 02:47:32 server sshd[27118]: User root from CLIENT_IP not allowed because listed in DenyUsers

With hosts.deny

sshd : CLIENT_IP

Client side debug log:

ssh_exchange_identification: Connection closed by remote host

Server Side log

Jul 2 02:46:28 server sshd[27100]: refused connect from CLIENT_IP (CLIENT_IP)

With PAM deny

Client Side log:

Permission denied (publickey,keyboard-interactive).

Server Side log:

PAM-listfile: Refused user xyz for service ssh

With Lock Account

Client Side log:

debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password Permission denied, please try again.

Server Side log:

Jul 2 02:57:16 server sshd[27303]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=CLIENT_IP user=usertest Jul 2 02:57:17 server sshd[27303]: Failed password for usertest from CLIENT_IP port 39431 ssh2 Jul 2 02:57:35 server sshd[27303]: Failed password for usertest from CLIENT_IP port 39431 ssh2

Then after doing some Google search, it's seems this issue because :

  • Duplicate IP in Your Network
  • Might be it's bug.
  • 3
    The "Connection reset by peer" is a generic socket error message; you would not find it in the SSH sources. Look for a network read in ssh_exchange_identification. Anyway, this looks more like a firewall issue or similar. – tripleee Jul 9 '13 at 12:50

This can happen if the routing between the two computers is different. It is worthwhile to look into both the routing configurations of the two endpoints as well as any firewalls that the packets pass through.

  • How, exactly, does the path that a packet takes affect whether or not the handshake succeeds??? – David Hoelzer Nov 8 '16 at 12:18

Try: ssh -2 name@ip or ssh -2 -l name ip

  • 4
    Do you want to explain how you think this is relevant? – jasonwryan Dec 9 '13 at 1:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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