Bug 821079 - failed SSH connection; seem to depend on SSH KEXINIT packet length
failed SSH connection; seem to depend on SSH KEXINIT packet length
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Lautrbach
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-05-11 15:11 EDT by Przemek Klosowski
Modified: 2012-05-11 19:46 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-05-11 19:46:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Przemek Klosowski 2012-05-11 15:11:11 EDT
Description of problem:
SSH connections fail (server sends RST after Client: Key Exchange Init)

Version-Release number of selected component (if applicable):
Client: openssh-5.9p1-22.fc17.x86_64
(talking to RHEL6.2 box serverA: openssh-server-5.3p1-70.el6_2.2.x86_64)

How reproducible: every time

Steps to Reproduce:
1. ssh -v serverA 
Actual results:
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

Expected results: successful SSH connection

Additional info:
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.
Comment 1 Przemek Klosowski 2012-05-11 15:29:45 EDT
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.
Comment 2 Przemek Klosowski 2012-05-11 15:33:41 EDT
Because of the possible security implications, I propose to make it HIGH priority/severity, until someone can exclude an exploitable SSH server vulnerability.
Comment 3 Przemek Klosowski 2012-05-11 19:46:07 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.