Description of problem: SSH connections fail (server sends RST after Client: Key Exchange Init) Version-Release number of selected component (if applicable): Client: openssh-5.9p1-22.fc17.x86_64 (talking to RHEL6.2 box serverA: openssh-server-5.3p1-70.el6_2.2.x86_64) How reproducible: every time Steps to Reproduce: 1. ssh -v serverA Actual results: ... debug1: SSH2_MSG_KEXINIT sent Read from socket failed: Connection reset by peer Expected results: successful SSH connection Additional info: 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 like that 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, 146 ciphers works while 147 ciphers cause the reset: ssh serverA -c aes128-ctr,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, Read from socket failed: Connection reset by peer ssh serverA -c aes128-ctr,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, Last login: Fri May 11 14:37:28 2012 from client.company.com 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 wand 1020 bytes for the successful connection. I suspect some kind of buffer overflow, probably in the server. I log this against the ssh client in F17, though, because previous ssh client in F16 did not trigger this problem. Please evaluate and reassign to the server component if you think it's justified.
Because of the possible security implications, I propose to make it HIGH priority/severity, until someone can exclude an exploitable SSH server vulnerability.
I did a simultaneous packet capture on both ends for the failed transaction, and I now believe it is the firewall's fault. The server is missing the KEX packet, and the subsequent RST packet is faked (on the server it arrives 'from the client' and on the client it arrives 'from the server': client server dir. packet contents ------ ------ ---- -------------------------------------------- OK OK c->s Client Protocol: SSH-2.0-OpenSSH_5.9\\r OK OK s->c ssh > 50709 [ACK] Seq=22 Ack=22 Win=14592 Len=0... OK missing c->s Client: Key Exchange Init OK missing s->c ssh > 50709 [RST] Seq=22 Win=0 Len=0 missing OK c->s 50709 > ssh [RST] Seq=22 Win=0 Len=0 In the above, 'client=OK' means that the packet was captured at the client, and similarly for the 'server=OK'. The 'dir.' column shows whether the captured packet claimed to be 'client->server' or the other way around. So it seems that our firewall is screwing us. Great. Sorry for the alarm. For a while there I thought that I found a buffer overflow in RHEL sshd.