Connection reset by peer

[TheREK3R]

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

[bes-internal]

What version of sshfs-win do you use?

[TheREK3R]

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 notifications@github.com 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: https://github.com/billziss-gh/sshfs-win/issues/95#issuecomment-502726282

[TheREK3R]

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

[Ciantic]

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:~ $

[cjwijtmans]

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?

[Ice-IX]

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

[dorkbox]

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

[bersbersbers]

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)

[bersbersbers]

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:

[cjwijtmans]

duplicate issue

https://github.com/billziss-gh/sshfs-win/issues/74

[billziss-gh]

@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?

[bersbersbers]

@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.

[shyjuk]

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.

[billziss-gh]

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.

[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

[sieempi]

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

[SonoCseos]

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.

[SonoCseos]

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.