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, 2012 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, 2012 at 13:04
  • Did you checked both SSH daemons are running? Anything in the logs ?
    – NorTicUs
    Oct 23, 2012 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, 2012 at 13:11

6 Answers 6

  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, 2014 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, 2015 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. Sep 11, 2017 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, 2013 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 Jul 8, 2014 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. May 20, 2013 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. May 21, 2013 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, 2016 at 15:03

You must log in to answer this question.

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