ssh 'connection reset by peer' problem since 5.8p1

[Corinna Vinschen]

On Feb 17 23:27, Darren Tucker wrote:
> On 17/02/2011 10:34 PM, Corinna Vinschen wrote:
> >As an additional datapoint, we had a couple of similar bug reports after
> >I upgraded openssh in the Cygwin distro to 5.7p1 and then 5.8p1.  One of
> >them even comes with a set of debug output of working (5.6p1) and
> >non-working (5.8p1) connection attempts:
> [...]
> >However, I tried with various older versions of SSH running on Cygwin,
> >Linux and Solaris to connect from 5.8p1 myself, and I'm unable to
> >reproduce this problem.
> 
> Thanks for the extra info.  I haven't been able to reproduce either.
> I've tried building 5.5p1 and 4.3p1 against (locally built) OpenSSL
> 0.9.6b and 0.9.8d.  There seems to be some piece of the puzzle
> missing...

What I'm missing in the debug output is a clear statement of the
side which closes the connection, *why* the connection has been
closed.  In Andrew's debug output The server side just contains:

  debug1: sending SSH2_MSG_KEX_ECDH_INIT
  debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
  Read from socket failed: Software caused connection abort

and the client side just contains:

  debug1: SSH2_MSG_KEXINIT sent
  Read from socket failed: Connection reset by peer

In Oren's debug output, server:

  debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
  debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
  Write failed: Connection reset by peer

client:

  debug1: SSH2_MSG_KEXINIT sent
  debug2: Network child is on pid 1403
  debug3: preauth child monitor started
  debug3: mm_request_receive entering
  Read from socket failed: Connection reset by peer

What happened here?  The socket got closed, but why?  In theory at
least one side of the connection should know...


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat