SSH connection problem and possible buffer overflow

[Przemek Klosowski]

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 
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.