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.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
