Connection reset by peer

I get this message every time when running ssh from powershell

command is

sshfs user@host:/path/to/home DRIVE:

it is authenticating successfully and then quitting

i could use some help fixing this

What version of sshfs-win do you use?

I am using the newest version that isnt in beta. I downloaded the msi yesterday

On Jun 17, 2019, 8:15 AM, at 8:15 AM, Vladimir Varlamov ***@***.***> wrote: What version of sshfs-win do you use? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #95 (comment)

any ideas, should i be using a certain set of options?

I'm getting this problem as well, however I downloaded latest beta for both:

PS C:\Program Files\SSHFS-Win\bin> .\sshfs.exe -o loglevel=debug3 -d pi@192.168.8.108:/home/pi X:
SSHFS version 3.5.2
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <pi@192.168.8.108> <-s> <sftp>
...
debug1: Authentication succeeded (password).
Authenticated to 192.168.8.108 ([192.168.8.108]:22).
...
debug3: read - ERROR from cb :87, io:000001B88F2FED40
debug2: channel 0: read<=0 rfd 4 len 4294967295
debug2: channel 0: read failed
...
read: Connection reset by peer

Version is the latest

PS C:\Program Files\SSHFS-Win\bin> .\sshfs.exe --version
SSHFS version 3.5.2
FUSE library version 3.2

Btw I also get System error 67 has occurred if I try to use the net use X: \\sshfs\pi@192.168.8.108\. If I type in the explorer address bar I get some error too.

Something is badly broken.

P.S. SSH and SFTP works, I've tried with ssh.exe provided by Windows 10 and with WinSCP:

PS C:\Program Files (x86)\WinFsp\bin> ssh pi@192.168.8.108
pi@192.168.8.108's password:
Linux raspberrypi 4.19.57-v7l+ #1244 SMP Thu Jul 4 18:48:07 BST 2019 armv7l
Last login: Wed Jul 17 18:14:23 2019 from 192.168.8.102
pi@raspberrypi:~ $

I think i figured out what might be the issue here.
If you have windows ssh support installed it might interfere perhaps.
PS C:\program files\sshfs-win\bin> ssh -V OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
PS C:\program files\sshfs-win\bin> .\ssh.exe -V OpenSSH_7.9p1, OpenSSL 1.0.2r 26 Feb 2019

SSHFS might not be calling the correct ssh program?

I had this very same issue - for whatever reason it doesn't matter if you have the path set in the environment variable or not, the path NEEDS to be set inside the command prompt before running the command. For me, running just

sshfs.exe -f user@host: z:

gives me

read: Connection reset by peer

but running

set PATH=C:\Program Files\SSHFS-Win\bin
sshfs.exe -f user@host: z:

allows me to connect successfully

If you change the environment variables in windows to move SSHFS\bin ABOVE the windows SSH bin directory, it works.

And by the way: a very easy typo (forgetting the final colon on user@host:) can lead to essentially the same error message ("Connection reset by peer"), as you can see:

C:\Program Files\SSHFS-Win\bin>.\sshfs.exe -d user@host: X:
SSHFS version 3.5.2
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <user@host> <-s> <sftp>

(connects to the correct host, at least)

C:\Program Files\SSHFS-Win\bin>.\sshfs.exe -d user@host X:
SSHFS version 3.5.2
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <X> <-s> <sftp>
read: Connection reset by peer

(tried to connect to X)

@dorkbox

I had this very same issue - for whatever reason it doesn't matter if you have the path set in the environment variable or not, the path NEEDS to be set inside the command prompt before running the command.

This is not strictly correct. In fact, by issuing

set PATH=C:\Program Files\SSHFS-Win\bin

you are doing much more than adding C:\Program Files\SSHFS-Win\bin to PATH - you are effectively removing everything else from PATH by overwriting it. In effect, as soon as you do this, commands such as net use will fail.

As @dorkbox has commented, adding C:\Program Files\SSHFS-Win\bin before the Windows SSH bin directory works, both within and outside of that command prompt. That is basically

set PATH=C:\Program Files\SSHFS-Win\bin;%PATH%

But that is only a workaround, as you probably do not want to use SSHFS' ssh.exe system-wide. (There is a reason you had ssh.exe installed before, right?) So let's look at the real problem, which is that

C:\Program Files\SSHFS-Win\bin>.\sshfs.exe ...

should prefer an ssh.exe in the current directory over an ssh.exe somewhere else. The reason why it doesn't is that sshfs.exe sets its own working directory, internally - probably here:

https://github.com/libfuse/sshfs/blob/8340a67b31112a32469cca0e0a94f965d4200021/sshfs.c#L1191

So my proposed fix, without any PATH tinkering even with OpenSSH in the PATH, and without changing working directories, is this:

"C:\Program Files\SSHFS-Win\bin\sshfs.exe" -o ssh_command=bin/ssh.exe user@host: X:

duplicate issue

#74

@bersbersbers

@bersbersbers

Should sshfs-win.c always pass the option -o ssh_command=bin/ssh.exe (or perhaps -o ssh_command=/usr/bin/ssh.exe to avoid the problem of picking the wrong ssh.exe that some experience?

@billziss-gh

@billziss-gh

Should sshfs-win.c always pass the option -o ssh_command=bin/ssh.exe [...] to avoid the problem of picking the wrong ssh.exe that some experience?

Having thought about this for half a day, I would say yes. In light of this issue and its duplicates (#39, #74 and maybe more), there are a lot of related issues that would be solved. In addition, in my testing on my system, I have not found any other ssh.exe that works, except the one that your installer provides [no idea why - I'd love to use the Windows OpenSSH one because I could get rid of PuTTY's agent altogether] - so there won't be a lot of working setups that you would break this way.

Finally, users should still be able to pass another -o ssh_command=some_other_ssh.exe - and if I understand sshfs-win.c correctly, this will be appended after your internal -o ssh_command=bin/ssh.exe, so sshfs.exe should be able to ignore the former and retain only the latter (this needs to be tested). The only thing that would not be perfect is that in debug mode, when passing -o ssh_command=some_other_ssh.exe, one would see two -o ssh_command=..., but I really don't think that's a problem.

The alternative would be to reorganize the file structure of the installer to place ssh.exe not in bin, but one folder up where sshfs.exe would pick it up without bin/ - but I do not like that solution a lot.

or perhaps -o ssh_command=/usr/bin/ssh.exe

Both are working for me. I cannot really say why, as I have only a very basic idea how Cygwin paths work. I thought the issue may be related to this, but maybe it's not:
https://github.com/libfuse/sshfs/blob/8340a67b31112a32469cca0e0a94f965d4200021/sshfs.c#L1191
(This chdir however does explain why -o ssh_command=/bin/ssh.exe also works.)

Sorry I'm cannot be more helpful here.

sshfs.exe -f user@host: z:

Worked ! Thanks ..

set PATH=C:\Program Files\SSHFS-Win\bin
sshfs root@192.168.56.11:/ Z: &

Adding & exit to command prompt again.

Please try the latest release: SSHFS-Win 2021.1 Beta.

SSHFS-Win now passes the -o ssh_command=/usr/bin/ssh.exe to SSHFS, which should ensure that the right SSH always gets used regardless of PATH. Hopefully this will resolve this and similar issues.

Please try the latest release: SSHFS-Win 2021.1 Beta.

SSHFS-Win now passes the -o ssh_command=/usr/bin/ssh.exe to SSHFS, which should ensure that the right SSH always gets used regardless of PATH. Hopefully this will resolve this and similar issues.

It did not work for me.
using -ossh_command=bin/ssh.exe did work.

SSHFS version 3.5.2
FUSE library version 3.2

The issue was solved for me after deleting c:\Users[user].ssh\config (maybe an incompatibility with other installed versions of ssh)

@dorkbox

I had this very same issue - for whatever reason it doesn't matter if you have the path set in the environment variable or not, the path NEEDS to be set inside the command prompt before running the command.

This is not strictly correct. In fact, by issuing
set PATH=C:\Program Files\SSHFS-Win\bin
you are doing much more than adding C:\Program Files\SSHFS-Win\bin to PATH - you are effectively removing everything else from PATH by overwriting it. In effect, as soon as you do this, commands such as net use will fail.

As @dorkbox has commented, adding C:\Program Files\SSHFS-Win\bin before the Windows SSH bin directory works, both within and outside of that command prompt. That is basically
set PATH=C:\Program Files\SSHFS-Win\bin;%PATH%
But that is only a workaround, as you probably do not want to use SSHFS' ssh.exe system-wide. (There is a reason you had ssh.exe installed before, right?) So let's look at the real problem, which is that
C:\Program Files\SSHFS-Win\bin>.\sshfs.exe ...
should prefer an ssh.exe in the current directory over an ssh.exe somewhere else. The reason why it doesn't is that sshfs.exe sets its own working directory, internally - probably here:

https://github.com/libfuse/sshfs/blob/8340a67b31112a32469cca0e0a94f965d4200021/sshfs.c#L1191

So my proposed fix, without any PATH tinkering even with OpenSSH in the PATH, and without changing working directories, is this:
"C:\Program Files\SSHFS-Win\bin\sshfs.exe" -o ssh_command=bin/ssh.exe user@host: X:

I have tried this solution (and also the other with "set PATH=..."). In both cases, the command remains permanently stuck, no debug message appears.

@softlion

Please try the latest release: SSHFS-Win 2021.1 Beta.
SSHFS-Win now passes the -o ssh_command=/usr/bin/ssh.exe to SSHFS, which should ensure that the right SSH always gets used regardless of PATH. Hopefully this will resolve this and similar issues.

It did not work for me. using -ossh_command=bin/ssh.exe did work.
SSHFS version 3.5.2
FUSE library version 3.2

I have tried the beta release, but it did not do anything for me, like @softlion says. If I add the "-o ssh_command=bin/ssh.exe" it seems to get permanently stuck.

This issue is a duplicate of #74 where I posted some good news in #74 (comment)

@cjwijtmans

I had this very same issue - for whatever reason it doesn't matter if you have the path set in the environment variable or not, the path NEEDS to be set inside the command prompt before running the command. For me, running just

sshfs.exe -f user@host: z:

gives me

read: Connection reset by peer

but running

set PATH=C:\Program Files\SSHFS-Win\bin
sshfs.exe -f user@host: z:

allows me to connect successfully

@cjwijtmans wrote "...SSHFS might not be calling the correct ssh program?

So the reason setting the path works is that by doing so, you removed the problematic version of ssh from the path. Thank you, that works for me too.

I get "read: Connection reset by peer" either by using set PATH=C:\Program Files\SSHFS-Win\bin or by running .\sshfs.exe -o ssh_command=.\ssh.exe while inside the SSHFS-Win\bin directory.

SSHFS version 3.5.2
FUSE library version 3.2

edit: net use works.

On Sat, Feb 15, 2025 at 02:57:20AM -0800, shrx wrote: I get "read: Connection reset by peer" either by using `set PATH=C:\Program Files\SSHFS-Win\bin` or by running `.\sshfs.exe -o ssh_command=.\ssh.exe` while inside the SSHFS-Win\bin directory. SSHFS version 3.5.2 FUSE library version 3.2

Hello While in C:\Program Files\SSHFS-Win\bin, try running .\sshfs.exe -o ssh_command=".\ssh.exe -vvv"

…

-- Emmanuel Dreyfus ***@***.***

Hello

While in C:\Program Files\SSHFS-Win\bin, try running
.\sshfs.exe -o ssh_command=".\ssh.exe -vvv"
…

.\sshfs.exe -o ssh_command=".\ssh.exe -vvv" pi@192.168.1.113: P:
read: Connection reset by peer

Solved with $env:Path = 'C:\Program Files\SSHFS-Win\bin;' + $env:Path

Solved with $env:Path = 'C:\Program Files\SSHFS-Win\bin;' + $env:Path

This did the trick for me 🎊!

Navigation Menu

Repository navigation

Connection reset by peer #95

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Connection reset by peer #95

Description

Activity

bes-internal commented on Jun 17, 2019

TheREK3R commented on Jun 17, 2019

TheREK3R commented on Jun 27, 2019

Ciantic commented on Jul 17, 2019

cjwijtmans commented on Nov 8, 2019

Ice-IX commented on Dec 16, 2019

dorkbox commented on Apr 7, 2020

bersbersbers commented on Jun 30, 2020

bersbersbers commented on Jul 1, 2020

cjwijtmans commented on Aug 10, 2020

billziss-gh commented on Jan 7, 2021

bersbersbers commented on Jan 8, 2021

shyjuk commented on Jan 11, 2021

billziss-gh commented on Jan 12, 2021

softlion commented on Jul 20, 2023

sieempi commented on Dec 14, 2023

SonoCseos commented on Mar 27, 2024

SonoCseos commented on Mar 28, 2024

manu0401 commented on Nov 1, 2024

kenseehart commented on Nov 19, 2024

shrx commented on Feb 15, 2025

manu0401 commented on Feb 15, 2025

shrx commented on Feb 17, 2025

shrx commented on Feb 17, 2025

DaviidMM commented on Oct 30, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions