winfsp
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 [email protected]:/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)? [email protected]'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 [email protected]:/home/bernardo c:\joomla Cannot create WinFsp-FUSE file system: mount point in use.
C:\Program Files\SSHFS-Win\bin>sshfs [email protected]:/home/bernardo c:\joomla2 [email protected]'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 [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] 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 [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] 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 [email protected] 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 [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] 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
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: https://github.com/billziss-gh/sshfs-win/issues/54, https://github.com/billziss-gh/sshfs-win/issues/39, https://github.com/billziss-gh/sshfs-win/issues/64, https://github.com/billziss-gh/sshfs-win/issues/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
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 https://github.com/billziss-gh/sshfs-win/issues/95#issuecomment-652289412 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
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 https://github.com/billziss-gh/sshfs-win/issues/95#issuecomment-652289412 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 https://github.com/billziss-gh/sshfs-win/issues/95#issuecomment-652289412.
Edit: oh yes, and https://github.com/billziss-gh/sshfs-win/issues/95#issuecomment-758437010 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\[email protected]!2222\share\path X: works but does not background
Windows explorer map network drive X: with folder of \\sshfs.kr\[email protected]!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\[email protected]!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.
