I can SSH in one direction with no problems:


ssh user@computerA

but the other way:

ssh user@computerB

I get Read from socket failed: Connection reset by peer.

I don't even begin to know where to look to solve this.

Anyone have any clues?

  • What's your network configuration ? Is any of the machine behind a firewall/router ? – NorTicUs Oct 23 '12 at 12:54
  • Both just connected to each other over ethernet cable via a router. They have SSH'd in both directions in the past. – boehj Oct 23 '12 at 13:04
  • Did you checked both SSH daemons are running? Anything in the logs ? – NorTicUs Oct 23 '12 at 13:07
  • Good and bad news: I answered my own question. I'll type that out below. Thanks for your help all the same. – boehj Oct 23 '12 at 13:11
  1. start monitoring the server's log file

    tail -f /var/log/auth.log

  2. add -v to get a verbose output at the client end

    ssh user@computerB -v

This might give you more details about the cause. if the rsa and dsa keys are missing on the server, fix them by:

ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa  -f /etc/ssh/ssh_host_dsa_key
  • This worked for me. Though I had to be root to run the following: ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key – StarDust Jan 28 '14 at 0:48
  • Keys re-generation definitely work. In my case it was changing machine IP address after openssh installed (and keys generated during install). – Alfishe Apr 25 '15 at 2:25
  • After doing this I lost any chance of connecting to my server. Had to ask for hosting provider's help. Still awaiting their answer. Centos 7 with cPanel. – Tomas Gonzalez Sep 11 '17 at 15:59

I re-installed the SSH bits by doing:

sudo apt-get --reinstall install openssh-server openssh-client

This fixed all my problems.

  • 9
    Could be a coincidence. That the problem stopped happening at the time you reinstalled ssh isn't an airtight assurance of cause and effect. By the way, which side did you reinstall? Or both? In any case, "this question is unlikely to help future visitors". – Kaz Apr 3 '13 at 8:13

änthräX's method is very helpful. It works for me!

Basically I think, after installed ssh, key files are needed.

The only revision I made was to use rsa instead of rsa1:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key 
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

That modified method worked for me.

  • This was the problem in my case. The ssh server package with the current Ubuntu release for the Utilite ARM machine installed with the OP's symptom. After running these two commands (which I did as root), I can finally ssh in. Thanks a lot. +1 – James T Snell Jul 8 '14 at 16:30

It's because somehow the permissions of the files inside /etc/ssh have changed... So change the permission of the files like the example given below:


chmod 644 ssh_config
chmod 600 moduli

and so on...

Finally the file permissions should look like something like given below,

[root@hostname ssh]# ls -latr
total 172

-rw-r--r--.   1 root root   2047 Aug 12  2010 ssh_config
-rw-------.   1 root root 125811 Aug 12  2010 moduli
-rw-------.   1 root root    963 Mar  1 16:02 ssh_host_key
-rw-r--r--.   1 root root    627 Mar  1 16:02 ssh_host_key.pub
-rw-r--r--.   1 root root    382 Mar  1 16:02 ssh_host_rsa_key.pub
-rw-------.   1 root root   1675 Mar  1 16:02 ssh_host_rsa_key
-rw-r--r--.   1 root root    590 Mar  1 16:02 ssh_host_dsa_key.pub
-rw-------.   1 root root    668 Mar  1 16:02 ssh_host_dsa_key
-rw-------.   1 root root   3845 May  7 11:52 sshd_config

After changing the permissions try connecting from putty, should work fine..

  • 1
    Why is Putty relevant? And consider asking the OP what the permissions are on the files before advising that he/she change them. – Clive van Hilten May 20 '13 at 14:02
  • Extremely sorry for posting the answer in a wrong manner.Now here is the thing,during some app installation someone changed the permissions of these files to 777. This i got to know while going thru /var/log/messages (serial connecting to the machine). Hence changed the permissions, and guess what? it worked fine after that. – Varun Joseph May 21 '13 at 4:18

We had a similar problem, but it occurred only when logging from Ubuntu to Solaris. Making sure all these lines are present in /etc/ssh/ssh_config on the Ubuntu host fixed the problem (you should find some of these lines are already present):

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160

In the case of Xubuntu I needed only the last two.


This message can also stem from multiple attempted ssh attacks. If you're seeing this message in your logs, a malicious source may be attempting to ssh into your machine by using brute-force password attempts.

To slow down the attempts, install the package "fail2ban":

sudo apt-get install fail2ban

From fail2ban's wiki page:

Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs -- too many password failures, seeking for exploits, etc. Generally Fail2Ban is then used to update firewall rules to reject the IP addresses for a specified amount of time

  • 1
    Please explain your answer with more details on why this would work – DnrDevil Feb 13 '16 at 15:03

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