openssh bugs - Jul 2017 - [Bug 2750] New: Unexpected "Couldn't read packet: Connection reset by peer" message

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

            Bug ID: 2750
           Summary: Unexpected "Couldn't read packet: Connection reset
by
                    peer" message
           Product: Portable OpenSSH
           Version: 7.2p2
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sftp
          Assignee: unassigned-bugs at mindrot.org
          Reporter: jg at jguk.org

Hello
I didn't expect to get a message about "Couldn't read packet:
Connection reset by peer" - it seems the failure was just a missmatch
of available key type. Can this connection reset message be removed?


$ sftp -P 2222 ssh at 192.168.0.16
Unable to negotiate with 192.168.0.16 port 2222: no matching host key
type found. Their offer: ssh-dss
Couldn't read packet: Connection reset by peer

Note, "ssh" command does not have the same problem with this server,
it
doesn't show the connection reset message.

Thank you, Jonny

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> ---
What is the server?  Based on the key type it offers I'd guess it's an
old dropbear.

"connection reset by peer" usually means the other end has crashed, so
I'd suggest running whatever it is in its debug mode and seeing what
it's doing.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

--- Comment #2 from jg at jguk.org ---
Hello Darren

It was an Android app "SSH Server". Perhaps you're right and it
crashed. Was just a bit surprised to see the connection reset message.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to jg from comment #2)
> Hello Darren
> 
> It was an Android app "SSH Server". Perhaps you're right and
it
> crashed. Was just a bit surprised to see the connection reset
> message.
You can get more info out of the client by adding -oLogLevel=debug3 to
both ssh and sftp command lines and comparing them.  If you do, please
use "Add an attachment" to attach both logs to this bug so we can take
a look.

sftp invokes ssh and must consume its output, once that pipe is full
ssh will block until sftp does.  I suspect the different is due to a
race: without that blocking ssh initiates the close first, and with the
blocking the server crashes/exits before ssh gets around to closing the
connection.  If that's the case there's not much OpenSSH can do.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

--- Comment #4 from jg at jguk.org ---
Created attachment 3026
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3026&action=edit
sftp

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

--- Comment #5 from jg at jguk.org ---
Created attachment 3027
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3027&action=edit
ssh log

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

--- Comment #6 from jg at jguk.org ---
Hello Darren

Thank you. I have attached the logs.

BTW:
This has debug output:
sftp -oLogLevel=debug3 -P 2222 ssh at 192.168.1.15

This has *no* debug output:
sftp -P 2222 ssh at 192.168.1.15 -oLogLevel=debug3 

Is that a separate issue?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

--- Comment #7 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to jg from comment #6)
[...]
> This has debug output:
> sftp -oLogLevel=debug3 -P 2222 ssh at 192.168.1.15
> 
> This has *no* debug output:
> sftp -P 2222 ssh at 192.168.1.15 -oLogLevel=debug3 
> 
> Is that a separate issue?
No, that's just how getopt works.  Well, sometimes.  On some systems. 
It's complicated.

Quoting getopt(3) on Fedora:

"If  the first character of optstring is '+' or the environment
variable POSIXLY_CORRECT is set, then option  processing  stops as soon
as a nonoption argument is encountered."

and on OpenBSD:

"When all options have been processed (i.e., up to the first non-option
argument), getopt() returns -1."

If the getopt on the platform you're building on doesn't have a
particular feature (optreset) then the one in the compatibility code
will be used and that has the BSD semantics.  This is usually the case
on Linux.

ssh(1) is a bit special in that it'll accept -opts after the argument
(usually the host) regardless, but that behaviour dates back decades
and changing it now would probably break about a gazillion scripts.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

--- Comment #8 from Darren Tucker <dtucker at zip.com.au> ---
Comment on attachment 3027
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3027
ssh log

I can't see anything significant in either log, and they are identical
up until the point of failure.
>debug1: Remote protocol version 2.0, remote software version
SSHD-CORE-0.13.0
Looks like the server is either Apache Mina or a fork thereof.  You'd
have to ask the supplier of that server what it's doing.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #9 from Damien Miller <djm at mindrot.org> ---
The "Couldn't read packet" comes from sftp-client.c. Maybe we
could
either change this to a more friendly "ssh connection closed" or quiet
it entierly on the assumption that ssh has already printed something
when it exited?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

--- Comment #10 from jg at jguk.org ---
"Connection closed" does sound nicer. It seems like an error at the
moment.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned-bugs at mindrot.org |djm at mindrot.org
   Attachment #3031|                            |ok?(dtucker at zip.com.au)
              Flags|                            |

--- Comment #11 from Damien Miller <djm at mindrot.org> ---
Created attachment 3031
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3031&action=edit
friendlier fatal for ECONNRESET

Turns out we already have code to friendlify the error message, we just
need to consider ECONNRESET as well as EPIPE.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |2698


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2698
[Bug 2698] Tracking bug for OpenSSH 7.6 release
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3031|ok?(dtucker at zip.com.au)     |ok+
              Flags|                            |

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Damien Miller <djm at mindrot.org> ---
fixed; this will be in OpenSSH 7.6 - thanks!

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

--- Comment #13 from jg at jguk.org ---
Great work Damien!

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

--- Comment #14 from jg at jguk.org ---
(In reply to Darren Tucker from comment #7)
> (In reply to jg from comment #6)
> [...]
> > This has debug output:
> > sftp -oLogLevel=debug3 -P 2222 ssh at 192.168.1.15
> > 
> > This has *no* debug output:
> > sftp -P 2222 ssh at 192.168.1.15 -oLogLevel=debug3 
> > 
> > Is that a separate issue?
> 
> No, that's just how getopt works.  Well, sometimes.  On some
> systems.  It's complicated.
> 
> Quoting getopt(3) on Fedora:
> 
> "If  the first character of optstring is '+' or the
environment
> variable POSIXLY_CORRECT is set, then option  processing  stops as
> soon as a nonoption argument is encountered."
> 
> and on OpenBSD:
> 
> "When all options have been processed (i.e., up to the first
> non-option argument), getopt() returns -1."
> 
> If the getopt on the platform you're building on doesn't have a
> particular feature (optreset) then the one in the compatibility code
> will be used and that has the BSD semantics.  This is usually the
> case on Linux.
> 
> ssh(1) is a bit special in that it'll accept -opts after the
> argument (usually the host) regardless, but that behaviour dates
> back decades and changing it now would probably break about a
> gazillion scripts.
Hi Darren

would be good if options after would be processed too, I wonder if GNU
getopt() is ok. Or an alternative could be integrated.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2750

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #15 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.