SSH connection problem and possible buffer overflow

Przemek Klosowski przemek.klosowski at
Fri May 11 20:38:30 UTC 2012

I filed this under
but this may be a SSH buffer overflow problem so I decided to post a 
heads-up here.

I have Fedora desktops talking SSH to RHEL 6.2 servers. F16 worked fine, 
but I started getting mysterious connection failures with F17:

   ssh -v serverA
   debug1: SSH2_MSG_KEXINIT sent
   Read from socket failed: Connection reset by peer

This is vexing: I can ssh to an identically configured serverB. The only
difference that I can see: serverB is on the same subnet, whereas 
failing serverA is across some routers and an internal firewall.

A workaround is to specify the cipher:

ssh serverA -c aes128-ctr

I believe that aes128-ctr is the default cipher, so  it isn't a wrong 
cipher issue; instead, specifying it as above shortens the length of the 
SSH packet.

I can tune the length of the cipher field by specifying a whole bunch of 
empty ciphers, by adding varying numbers of comma-delimited empty fields 
to the aes128-ctr cipher. In my case, specifying 146 ciphers works while 
147 ciphers cause the reset:

ssh serverA -c 
Read from socket failed: Connection reset by peer

ssh serverA -c 
Last login: Fri May 11 14:37:28 2012 from

Now, here's the interesting thing: when I tracked both the failing and
succeeding SSH connection in Wireshark, the SSH protocol data in the 
Client: Key Exchange Init packet was 1028 bytes for the failing 
connection, and that packet was immediately followed by the RST packet 
from the server. In the succeeding connection the buffer was 1020 bytes 
and resulted in a successful connection.

More information about the devel mailing list