I filed this under https://bugzilla.redhat.com/show_bug.cgi?id=821079
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
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 the buffer was 1020 bytes
and resulted in a successful connection.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel