ssh 'connection reset by peer' problem since 5.8p1

[Oren Held]

On Wed, Feb 23, 2011 at 11:18:31AM +0000, Andrew Ng wrote:
> Oren Held <oren <at> held.org.il> writes:
> 
> > 1. I confirm that above fix works for me also. Alternatively, as reported in
> > Debian bug #612607, adding '-c aes128-ctr' to the ssh command line does the
> > trick as well.
> 
> The '-c aes128-ctr' workaround also works for Cygwin OpenSSH 5.8p1 connection
> issues. I tried using the '-c' option with the default list of ciphers from the
> SSH man page and this once again caused the connection issue. I then tried
> trimming down the list and this appeared to also fix the connection issue.
> 
> So could it be somehow related to this list of ciphers?

I've researched it a bit deeper. Surprisingly it's not a matter of which cipher to
choose, but of *how long the list of ciphers is*. I'll explain:
Doesn't work:
-c 'aes128-ctr' and 94 commas (i.e. -c 'aes128-ctr,,,,,,,,,,,,,,,,,,' etc),
Does work:
-c 'aes128-ctr' and 95 commas

Now the number above varies. On my home computer it was 105 commas vs. 104
commas. So eventually I bet it has to do with SSH packet size.  For instance in
my place, according to Wireshark, SSH "Client: Key Exchange Init" packet length
is 1044+10(padding) in the bad case, 1036+4 in the good case. 

So to sum it all up:
1. Problem started with 5.7p1
2. Occurs on specific, bleeding edge Linux clients (probably some lib involved)
3. Occurs when connecting to specific old Linux ssh servers.
4. Long cipher list triggers the problem, shortening cipher list works around it.
   Length of doom is relative to the client or its network configuration.

#2 + #3 are still not clear to me - what environment is needed for reproduction.

Oren