SSH connection problem and possible buffer overflow
przemek.klosowski at nist.gov
Fri May 11 23:42:18 UTC 2012
On 05/11/2012 04:58 PM, Björn Persson wrote:
> Przemek Klosowski wrote:
>> 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.
> If serverA and serverB are running the same version of the SSH server, then
> I'd suspect the firewall. Many firewalls have a bad habit of mangling data and
> violating protocols. Is it possible for you to see what it looks like from the
> server side? For example, does the SSH server crash or does it also receive an
> RST packet?
You are right.. I did a simultaneous packet capture on both ends for the
failed transaction, and 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
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.
More information about the devel