Bug 821079
| Summary: | failed SSH connection; seem to depend on SSH KEXINIT packet length | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Przemek Klosowski <przemek> |
| Component: | openssh | Assignee: | Petr Lautrbach <plautrba> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 17 | CC: | mattias.ellert, mgrepl, plautrba, tmraz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-05-11 23:46:07 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Przemek Klosowski
2012-05-11 19:11:11 UTC
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. |