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@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
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.
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.
(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.
Created attachment 3026 [details] sftp
Created attachment 3027 [details] ssh log
Hello Darren Thank you. I have attached the logs. BTW: This has debug output: sftp -oLogLevel=debug3 -P 2222 ssh@192.168.1.15 This has *no* debug output: sftp -P 2222 ssh@192.168.1.15 -oLogLevel=debug3 Is that a separate issue?
(In reply to jg from comment #6) [...] > This has debug output: > sftp -oLogLevel=debug3 -P 2222 ssh@192.168.1.15 > > This has *no* debug output: > sftp -P 2222 ssh@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.
Comment on attachment 3027 [details] 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.
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?
"Connection closed" does sound nicer. It seems like an error at the moment.
Created attachment 3031 [details] 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.
fixed; this will be in OpenSSH 7.6 - thanks!
Great work Damien!
(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@192.168.1.15 > > > > This has *no* debug output: > > sftp -P 2222 ssh@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.
closing resolved bugs as of 8.6p1 release