Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I compiled OpenSSH_6.6p1 on one of our server. I am able login via SSH to the upgraded server. But I am not able to connect to other servers running OpenSSH_6.6p1 or OpenSSH_5.8 from this. While connecting I am getting an error as below.

Read from socket failed: Connection reset by peer

On the destination server in the logs, I am seeing it as below.

sshd: fatal: Read from socket failed: Connection reset by peer [preauth]

I tried specifying the cipher_spec [ ssh -c aes128-ctr destination-server ] as mentioned in here and was able to connect. How can configure ssh to use the cipher by default? Why is the cipher required here?

share|improve this question
From the server from which you get this error, what happens when you do telnet 22? – MadHatter Mar 24 '14 at 12:39
Both sides seem to think the other side closed the connection. At this point I would break out tcpdump or wireshark and run it on both ends. – Michael Hampton Mar 24 '14 at 12:41
@MadHatter I am able to telnet on port 22 and get SSH response. – nitins Mar 25 '14 at 6:13
OK, thanks nitins, just checking the basics. – MadHatter Mar 25 '14 at 7:27
Try compiling previous versions of openssh like 6.5p1 to see if this behaviour is due to a change in codebase? – user130370 Mar 25 '14 at 10:08
up vote 7 down vote accepted

The problem sounds like a server-side bug. When the client sends the list of ciphers the openssh server probably expects to be able to read the list in a single system call.

If the list of supported ciphers is longer than can be transmitted in one packet, the server may get fewer bytes in the first call than it expected. The correct behavior on the server would be to perform another call to get the rest of the bytes. But from the problem description it appears, the server instead closes the connection when it did not get the full list of ciphers at once. When the next packet from the client arrives, the server will send a connection reset to the client.

Configuring the client to use a shorter list of ciphers would then work around the bug. The openssh client will look for the list of ciphers in the following places:

  1. On the command line using either -c cipher_spec or -o Ciphers=cipher_spec
  2. In ~/.ssh/config by specifying Ciphers cipher_spec in the relevant host section or before the first host.
  3. In /etc/ssh/ssh_config using the same format as ~/.ssh/config
  4. A default list built into the client at compile time.

The two configuration files are respectively per-user and system-wide settings. Using Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc like Eric suggested should work fine.

share|improve this answer

You can specify cipher in ssh config file (/etc/ssh/ssh_config or similar, depends on $PREFIX etc). Any option you pass to ssh client on command line can be set in ssh (client) config file.

Here is the relevant line (just uncomment):

#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
share|improve this answer

My way to fix it, hope it helps someone :

# Recreate host keys
sudo rm /etc/ssh/ssh_host_*
sudo ssh-keygen -A

# Re-install SSh
sudo apt-get --reinstall install openssh-server openssh-client

Edit sshd_config by adding a value

add :  MaxAuthTries 3

Edit ssh_config by uncommenting a value

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
share|improve this answer

In my case this problem appeared because of asymmetric routing. Packets from client to server go directly, but packets from server to client were sent through the router.

Adding route to client subnet on the server fixed the problem.

share|improve this answer

Start monitoring the server's log file

tail -f /var/log/auth.log

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

Note: Keys re-generation definitely work.

share|improve this answer

My problem that had the exact same symptoms you are seeing was due to truncated host keys. Try recreating them with:

sudo rm /etc/ssh/ssh_host_*
sudo ssh-keygen -A
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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