work in ssh but not work in sshfs

In the image you can see an ssh terminal showing a ls -lah from a folder that can not be accessed via ssshfs

Windows 10 1809
sshfs-win-2.7.17334-x64.msi
winfsp-1.3.18160.msi

note my home folder work fine

I think it is better to run sshfs from the command line (found in \Program Files\SSHFS-Win\bin) and specify the path that you want to mount directly.

I try

C:\Program Files\SSHFS-Win\bin>sshfs bernardo@joomla.furg.br:/home/bernardo j:
The authenticity of host 'joomla.furg.br (2804:0:5400:dc::110)' can't be established.
ECDSA key fingerprint is SHA256:CRKF8JZhLBZVDWUXV7fTXk4ATIYjSecH7XnCgRTxRBY.
Are you sure you want to continue connecting (yes/no)?
bernardo@joomla.furg.br's password:
read: Connection reset by peer

C:\Program Files\SSHFS-Win\bin>mkdi \joomla
'mkdi' não é reconhecido como um comando interno
ou externo, um programa operável ou um arquivo em lotes.

C:\Program Files\SSHFS-Win\bin>mkdir \joomla

C:\Program Files\SSHFS-Win\bin>sshfs bernardo@joomla.furg.br:/home/bernardo c:\joomla
Cannot create WinFsp-FUSE file system: mount point in use.

C:\Program Files\SSHFS-Win\bin>sshfs bernardo@joomla.furg.br:/home/bernardo c:\joomla2
bernardo@joomla.furg.br's password:
read: Connection reset by peer

In neither case did it work

Another attempt was made to
on the server I created a symbolic link inside my homedir for / var / www / admin in putty works fine

but when I try to access the symbolic link via windows drive.

Just to pitch in, that I have the same issue. When running sshfs from command line, I got the "Connection reset by peer" error eventhough ssh (from the same exact directory with the same parameter) worked just fine.

I have the same issue.

When connecting via FileZilla or Microsoft's OpenSSH client, I am able to connect to the server without issue.

From my sshfs-win directory, running ssh.exe works correctly, with...

c:\Program Files\SSHFS-Win\bin>ssh.exe jpreston@my-ssh-server

Attempting to run sshfs....

c:\Program Files\SSHFS-Win\bin>sshfs jpreston@my-ssh-server:/ z:                                                       jpreston@my-ssh-server's password:
read: Connection reset by peer

The server is running Ubuntu 18.04, with OpenSSH server installed, and port 22 opened for incoming connections via the firewall.

Any ideas why this might be happening?

If you run it in debug mode you'll see it doesn't fine ssh.exe. Add 'C:\Program Files\SSHFS-Win\bin' to your PATH and it'll work,

I am having a similar issue. Was able to map my E: drive to an Ubuntu server, but when I restarted my computer recently it could not re-connect to the drive (note, I have restarted my computer before without any issue). Any attempt to re-map the drive has been unsuccessful.

Command line using 'sshfs'

Command line using 'net use'

Output from WinFsp diag.bat (I've seen other people need this, i don't know if it'll help)
diag.txt

A couple notes:

I can ssh just fine into the server
I have added C:\Program Files\SSHFS-Win\bin to my path with no avail
I have tried almost every combination of '/', '', and ':' for the path with nothing working

Any help would be much appreciated!

Tried versions 2.7, 3.2, and 3.5. These are logs from 2.7.

debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 192.168.0.14 ([192.168.0.14]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 1764, received 2316 bytes, in -3.8 seconds
debug1: Exit status 0
read: Connection reset by peer

ssh succeeds though.

debug1: Authentication succeeded (password).
Authenticated to 192.168.0.14 ([192.168.0.14]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
Welcome to Ubuntu 19.04 (GNU/Linux 5.0.0-16-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Thu Jun 13 19:43:47 UTC 2019

  System load:  0.0               Processes:             145
  Usage of /:   71.4% of 9.78GB   Users logged in:       1
  Memory usage: 22%               IP address for enp0s3: 192.168.0.14
  Swap usage:   0%


0 updates can be installed immediately.
0 of these updates are security updates.


root@vm:~# logout
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to 192.168.0.14 closed.
Transferred: sent 2320, received 3096 bytes, in 46.1 seconds
Bytes per second: sent 50.3, received 67.1
debug1: Exit status 0

If you compare the two, what seems to be failing is sftp.

Server log at that point:

Starting session: subsystem 'sftp' for root from 192.168.0.10 port 43787 id 0
debug1: SELinux support disabled
debug1: PAM: reinitializing credentials
debug1: permanently_set_uid: 0/0
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 14907
debug1: session_exit_message: session 0 channel 0 pid 14907
debug1: session_exit_message: release channel 0
Received disconnect from 192.168.0.10 port 43787:11: disconnected by user
Disconnected from user root 192.168.0.10 port 43787

Here's sshfs with loglevel=debug3:

debug1: Authentication succeeded (password).
Authenticated to 192.168.0.14 ([192.168.0.14]:22).
debug2: fd 4 setting O_NONBLOCK
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: subsystem request accepted on channel 0
debug3: read - ERROR from cb :87, io:0000020DD3CA29C0
debug2: channel 0: read<=0 rfd 4 len 4294967295
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug3: send packet: type 96
debug2: channel 0: input drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

debug3: send packet: type 1
debug3: fd 0 is not O_NONBLOCK
debug3: fd 1 is not O_NONBLOCK
Transferred: sent 1760, received 2304 bytes, in 0.5 seconds
Bytes per second: sent 3222.0, received 4217.9
debug1: Exit status 0
read: Connection reset by peer

What is debug3: read - ERROR from cb :87, io:0000020DD3CA29C0?

3.5 produces: debug3: read - ERROR from cb :87, io:0000027D79613C80.

I have beta version (SSHFS 3.5.2 and FUSE 3.2), and I get same problem:

debug3: read - ERROR from cb :87, io:00000172E5D18E80
...
read: Connection reset by peer

Same problem with 2.7.17334. sftp works fine though

debug3: read - ERROR from cb :87, io:000002D871B740B0
...
read: Connection reset by peer

+1

same problem "connection reset by peer"

Same problem debug3: read - ERROR from cb :87, io:0000012604E651C0 which then results in read: Connection reset by peer .

Version used WinFsp 2019.3 B4 and SSHFS-Win 3.5 BETA

Related: #54, #39, #64, #95

Not sure if this helps in diagnosing the issue but
if i use sshfs-win.exe to launch sshfs.exe from a cmd.exe prompt ref like below i get the following:

sshfs-win cmd -o loglevel=debug3 -d -p 5555 john@localhost:/../.. Z:
SSHFS version 3.5.2
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug3> <-oPort=5555> <-2> <john@localhost> <-s> <sftp>
Bad owner or permissions on /cygdrive/c/Users/john/.ssh/config
read: Connection reset by peer

@couilllard45682 Is right I believe, 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

@Ice-IX

Thanks for the follow up @Ice-IX but i'm getting the same error message after explicitly setting the path in the prompt.

@couilllard45682 Is right I believe, 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

Same problem here, and setting the path solved it!

See #95 (comment) for a solution to this issue which does not require any PATH tinkering, and follow that issue for maybe a fix to sshfs-win as well.

@couilllard45682 Is right I believe, 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

Works like a charm, thank you.

Weird enough, I tried adding SSHFS-Win folder path to the PATH variable of both my user and the whole system (to avoid entering it each time), but it doesn't work.

Now, it would be great if SSHFS-Win could be mapped to a drive letter, like Z:. Does anyone know how to do it?

Thank you!

EDIT: Typo

@nufrankz

@nufrankz

Weird enough, I tried adding SSHFS-Win folder path to the PATH variable of both my user and the whole system (to avoid entering it each time), but it doesn't work.

This is not weird at all, because the fix that you applied does not work by only adding SSHFS-Win to PATH, but primarily by removing everything else from it. See #95 (comment) for a better solution.

You might also try adding SSHFS-Win to the beginning of your PATH (instead of the end), but that will break other things on your system. I can only recommend you read #95 (comment).

Edit: oh yes, and #95 (comment) of course.

I was faced with the same error.
However, It worked fine by just changing the key to the key generated in Windows ssh-keygen.

The cause of this may be different from what is discussed in this issue, but I got the same error message.

debug3: read - ERROR from cb :87

So I note it for reference.

# On Windows
$ where ssh-keygen
C:\Windows\System32\OpenSSH\ssh-keygen.exe

$ ssh -V
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

# On Linux
$  ssh -V
OpenSSH_8.4p1 Debian-6, OpenSSL 1.1.1l  24 Aug 2021

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

.\sshfs-win.exe svc \sshfs.kr\vagrant@127.0.0.1!2222\share\path X: works but does not background

Windows explorer map network drive X: with folder of \\sshfs.kr\vagrant@127.0.0.1!2222\share\path does not work, Error code 0x800704b3 (network path does not exist)

Nor does net use x: \sshfs.kr\vagrant@localhost!2222\share\path System Error 67.

Without the .kr option am prompted Enter the user name for 'sshfs':

Temporary workaround:

Start-Process -NoNewWindow -filepath "C:\Program Files\SSHFS-Win\bin\sshfs-win.exe" -ArgumentList "svc \sshfs.kr\vagrant@127.0.0.1!2222\share\path X:"

Of course I have edited ~/.ssh/config to the location of the private key

Host 127.0.0.1
    Hostname        127.0.0.1
    Port            2222
    IdentityFile    ~/devops/.vagrant/machines/ubuntu/virtualbox/private_key
    User            vagrant

Not using the net use or the windows map network drive and instead using sshfs-win.exe seems to be working much better. Just need to script the reconnection when the server drops connection.

Hello everyone

There are two ssh.exe available, one bundled with sshfs-win in C:\Program Files\SSFS-Win\bin and the other from Microsoft in C:\Program Files\OpenSSH. The former works with sshfs-win but cannot use Windows built-in ssh-agent, while the later is incompatible wuth sshfs-win and leads to the now infamous "debug3: read - ERROR from cb :87" error.

If PATH has C:\Program Files\OpenSSH before C:\Program Files\SSFS-Win\bin , ssh works but sshfs-win does not.

A first workaround had been documented earlier in this issue: prepend C:\Program Files\SSFS-Win\bin to PATH so that the compatible ssh.exe is used.

But that does not let you use Windows built-in ssh-agent. You would need a fix to Microsoft ssh.exe so that it works with sshfs-win. I submitted that fix here:
PowerShell/openssh-portable#759

@manu0401

Thanks @manu0401!! For anyone else who's running into this same problem, it looks like we're still waiting on an official release from Microsoft which includes the fix mentioned above. Until then our only options to use sshfs-win seem to be:

Build & install the latest openssh-portable locally - should allow using keys from the MS ssh-agent
Use password-based auth (bad - password stored in plaintext)
Use key-based auth with a passwordless key (bad - insecure)

@erik434

@erik434 This is correct.

Note that building OpenSSH is not difficult, you just need enough disk space to install Visual Studio.

@manu0401

Thanks @manu0401! As you said, building OpenSSH wasn't bad - I followed their instructions here and deployed it by copying everything in bin\x64\Release (except the "unittest-*" folders) to C:\Program Files\OpenSSH.

However, now I see that the latest release of sshfs-win (over 4 years old now) also needs your patch for it to handle this automatically. I can work around that by running sshfs-win after manually setting OPENSSH_STDIO_MODE=nonsock - then it works! The OPENSSH_STDIO_MODE environment variable is inherited by the child ssh processes.

Unfortunately the latest release of sshfs-win-manager (also ~4 years old) seems to start sshfs-win in a totally clean environment (it does not inherit OPENSSH_STDIO_MODE from the parent sshfs-win-manager process).

I could have just wrapped a raw sshfs-win call in a .bat script to set up the environment (and run the .bat at startup), but I was stubborn and spent way too long trying to wrap sshfs-win.exe in a way that could make it work when called from sshfs-win-manager; that didn't pan out! I also tried and failed to build sshfs-win-manager - not familiar with the node ecosystem and had TONS of npm errors when trying to install dependencies.

I still wanted a GUI, so I ended up uninstalling sshfs-win-manager and instead installed SiriKali (winget install FrancisBanyikwa.SiriKali) which seems to be actively developed. It was a little awkward to get set up, but with some tweaking I was able to get it working with the new OpenSSH build. I posted a few more details on this thread if interested: mhogomchungu/sirikali#226

Update: the latest MS OpenSSH release 9.8.2.0, now available via winget, includes manu0401's patch, so there's no need to build OpenSSH yourself anymore.

@simoncerman

@simoncerman dont spam.

I had the same issue where net use or Windows Explorer failed with System Error 67 "network name not found" when trying to mount via SSHFS-Win, even with the correct server and credentials.

Reason: Windows had cached a corrupted credential in Credential Manager for the path \\sshfs.r\.... Because of this, each new mount attempt failed immediately with "invalid password."

Solution:

Remove the cached entry from Credential Manager (via cmdkey /delete:"LegacyGeneric:target=\\sshfs.r\user@server!port\home\...").

After clearing the cached credential, everything worked normally again.

I also ran into an issue with SSHFS-Win where the mount fails if another SSH binary is installed. The error looks like this:

PS C:\Users\henri> C:\Progra~1\SSHFS-Win\bin\sshfs.exe -o loglevel=debug3 -d xxx@xxxx:/xxx X:
[...]
debug3: read - ERROR from cb :87, io:00000215C31A4D90
debug2: channel 0: read failed rfd 4 maxlen 32768: Unknown error
debug2: channel 0: read failed
[...]
debug1: Exit status 0
read: Connection reset by peer

Cause:
SSHFS-Win always locates the SSH binary using the system PATH. This can fail if another SSH binary exists in the PATH or appears before SSHFS-Win.

Solution:
Use the ssh_command option to explicitly specify SSHFS-Win’s SSH binary. This avoids modifying the system PATH or interfering with other setups.

C:\Progra~1\SSHFS-Win\bin\sshfs.exe -d xxx@xxxx:/xxx X: -o ssh_command="C:\Progra~1\SSHFS-Win\bin\ssh.exe"

Notes:

Make sure the path to ssh.exe matches your SSHFS-Win installation.
Use the short path (C:\Progra~1\SSHFS-Win\bin\ssh.exe) to avoid space-related issues.

Navigation Menu

Repository navigation

work in ssh but not work in sshfs #74

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

work in ssh but not work in sshfs #74

Description

Activity

billziss-gh commented on Nov 14, 2018

dioubernardo commented on Nov 21, 2018

dodysw commented on Nov 28, 2018

jpreston84 commented on Jan 11, 2019

couillard45682 commented on Apr 18, 2019

cbochs commented on Jun 6, 2019

fireundubh commented on Jun 13, 2019

Ciantic commented on Jul 17, 2019

logust79 commented on Jul 17, 2019

adizhol commented on Sep 3, 2019

cjwijtmans commented on Nov 8, 2019

matijagrcic commented on Dec 10, 2019

Ice-IX commented on Dec 17, 2019

matijagrcic commented on Dec 17, 2019

craigmcfly commented on Jul 10, 2020

bersbersbers commented on Jan 8, 2021

nufrankz commented on May 3, 2021

bersbersbers commented on May 3, 2021

shirayu commented on Oct 7, 2021

sieempi commented on Dec 14, 2023

johnrclark3 commented on Jan 18, 2024

manu0401 commented on Nov 1, 2024

erik434 commented on Mar 20, 2025

manu0401 commented on Mar 20, 2025

erik434 commented on Apr 1, 2025

cjwijtmans commented on Jun 9, 2025

harlanecastro commented on Aug 30, 2025

Diblo commented on Sep 13, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions