sftp Couldn't read packet: Connection reset by peer

J.A. Neitzel gsocsftp at v6shell.org
Wed Apr 8 11:46:16 EST 2009


Hello Jon,

Jon Grant wrote:

> Hello
>
> 2009/4/7 J.A. Neitzel <gsocsftp at v6shell.org>:
> [..]
> > Bug added to Bugzilla.
> > See https://bugzilla.mindrot.org/show_bug.cgi?id=1588 for details.
>
> thank you for adding the patch to bugzilla.

I am glad to help, but getting the patched code committed to the
source trees is something that is beyond my control.  I do not have
commit access, and there is a related issue that could probably be
addressed in the same set of patches.

See, there is also a message, Attaching to %s..., that could be
turned into a debug message instead.

> Re the output text, my understanding is it would now look like with
> numbers added:
>
> 1) j at laptop:~$ sftp oops at unknown-web-qbcdef.com
> 2) ssh: Could not resolve hostname unknown-web-qbcdef.com: Name or
> service not known
> 3) Couldn't read packet: Connection reset by peer

Yes.

> So just to confirm, are (2) and (3) lines both needed? If it is me,
> and it "could not resolve the host name" I would not try and read a
> packet after that.

Yes, in essence, they are both needed.  The fact that sftp calls
ssh to connect to the server on the user's behalf is why you see
two error messages, one from ssh and one from sftp.  I could be
wrong, but the cost vs. the benefit of turning the two messages
into one might not be worth it.

Someone else could probably do a better job of explaining this than
I can since I am not yet completely familiar with the sftp-related
source code.

> Also for the English, "Couldn't" is different from "Could not" on the
> line above. Normally the short form is only used colloquially, so I
> would suggest to change (3) to be "Could not" if it is being retained.

Since "...n't" is a pattern used throughout the OpenSSH source tree,
I suspect that someone in charge would need to make such a decision.

Cheers,
Jeff
-- 
J.A. Neitzel
V6 Thompson Shell Port - http://v6shell.org/


More information about the openssh-unix-dev mailing list