sshfs-win cmd vs sshfs

[andyneff]

Sometimes I have to use sshfs-win cmd, and other times I have to use sshfs.exe directly. What is the cause of the discrepancy?

Version info

SSHFS version 3.5.2
FUSE library version 3.2
WINFSP 1.6
Windows 10 Pro: 10.0.19041

Works

• sshfs-win cmd {username}@{computername}:/home/{username}/bin x:
  • Both password or keyboard interactive authentication work
• sshfs andy@viola:/tmp X: -o ssh_command="wsl ssh"

Does not work

• sshfs {username}@{computername}:/home/{username}/bin x:
  • Results in: read: Connection reset by peer After entering my password, whether using password or keyboard interactive authentication
• sshfs-win cmd andy@viola:/tmp X: -o ssh_command="wsl ssh"
  • Results in read: Connection reset by peer, even if I'm using a shared connection, that has no password needed!

Additional information

• My particular remote computer uses a "one time use password" to log in (so you can never "remember password"), and I find it useful to use "connection sharing". Unfortunately, all (as far as I know) pure windows implementations of ssh do not support unix socket files (since cygwin/mingw/window's ssh implementations refuse to emulate it...). However WSL 1 does not have this problem. This is why I use the WSL's ssh, which has the following ~/.ssh/config files:

  Host *
    PreferredAuthentications password,keyboard-interactive
    IdentitiesOnly yes
    ServerAliveInterval 30
    ServerAliveCountMax 1
    ControlPersist 500
    ControlPath=~/.ssh/%C
    ControlMaster=auto
  

  • All I need to do is ssh in on WSL first, and I'm able to have password-less and secure ssh login (with out using an unencrypted Private key or ssh agent)

[billziss-gh]

Works

• sshfs-win cmd {username}@{computername}:/home/{username}/bin x:
  • Both password or keyboard interactive authentication work
• sshfs andy@viola:/tmp X: -o ssh_command="wsl ssh"

SSHFS-Win is only supposed to work with the SSH that ships with it.

• The first command works because it picks up the shipped SSH.

• The second command works because... actually I have never tried to use the WSL SSH with Cygwin SSHFS and I am surprised that this works at all! (Could it be that the -o ssh_command
  is ignored?)

Does not work

• sshfs {username}@{computername}:/home/{username}/bin x:
  • Results in: read: Connection reset by peer After entering my password, whether using password or keyboard interactive authentication
• sshfs-win cmd andy@viola:/tmp X: -o ssh_command="wsl ssh"
  • Results in read: Connection reset by peer, even if I'm using a shared connection, that has no password needed!

There is a version of OpenSSH that ships with many Windows 10 systems. It is likely that your PATH picks up that SSH instead of the one that ships with SSHFS-Win.

---

Since it seems that you are looking for advanced scenarios which SSHFS-Win does not support by default, I recommend building SSHFS under Cygwin on your own and experimenting from there. All the necessary patches to make SSHFS run on Cygwin/Windows have been upstreamed to to libfuse/sshfs. You will also need WinFsp with "FUSE for Cygwin" installed.

[andyneff]

Ah, I missed that. You are 100% right on why

sshfs {username}@{computername}:/home/{username}/bin x:

Doesn't work. Without setting the PATH (as you do for me with sshfs-win cmd) it is picking up the wrong ssh.

---

• (Could it be that the -o ssh_command
  is ignored?)

It does not appear to be ignore, as the right ssh is being called.

---

• sshfs-win cmd andy@viola:/tmp X: -o ssh_command="wsl ssh"

Ah! That too is a path problem! (I was in "password-less mode", do it didn't dawn on me it wasn't finding wsl, which is the problem.)

.\sshfs-win cmd {username}@{computername}:{dirname} X: -o ssh_command="c:\\\\windows\\\\system32\\\\wsl ssh"

Does indeed work flawlessly!!!

---

I admit, using wsl ssh is an advanced use case, but its exciting to know that works!

1. Would you mind a PR adding that as an advanced-advanced use case to the README? Or would you rather not deal with other crazies like me?
2. Just out of curiosity, why does windows ssh not work? (I think I understand why calling git ssh doesn't work, the cygwin dlls on the path will break mingw's ssh) Does windows use some Microsoftian encoding?

[billziss-gh]

1. Would you mind a PR adding that as an advanced-advanced use case to the README? Or would you rather not deal with other crazies like me?

I would not mind a PR, but the biggest problem is that right now I am over-worked with multiple projects so that I would not have time to independently verify and understand why it works.

For example, I find it very surprising that SSHFS:

• Works with Cygwin SSH (expected).
• Does not work with native Windows SSH (expected, because the Cygwin IPC mechanisms do not match the native Windows ones in many cases).
• Works with WSL SSH (entirely unexpected).

BTW, is that WSL1 or WSL2 SSH? (I expect WSL1).

So send a README PR but please be ready to answer questions about it in this issue list, because I will be @'ing you a lot if others fail to replicate your results :)

2. Just out of curiosity, why does windows ssh not work? (I think I understand why calling git ssh doesn't work, the cygwin dlls on the path will break mingw's ssh) Does windows use some Microsoftian encoding?

I have never investigated the full reasons. My reasoning is that the way I package SSHFS-Win it is supposed to use the shipped SSH; any other scenarios are unsupported.

A brief look in the SSHFS code finds that it uses a UNIX domain socket, which are not supported in native Windows. And then I find this article, which may explain why this works on WSL.

But do not ask me how the Cygwin implementation of a UNIX domain socket can interoperate with the one used in WSL.

[andyneff]

I wouldn't dare ask you why the WSL one works! Thanks for the explanation, I'll look into it some...

I am using WSL 1 primarily because microsoft/WSL#4246 Prevents me from using WSL 2 for real work.

I was surprised to hear sshfs uses a Unix domain socket... I just naively assumed everything was stdin/stdout. Then again I never care much to learn HOW stfp works. I too am totally shocked! (I will attempt a local WSL2 just to share with you my findings (and before any PRs, just so I can make sure they are as clear as possible).

Thanks for the reading material!

[billziss-gh]

I too find this stuff interesting, but unfortunately these days I have a lot of private work and little time to progress my investigations on WSL1, etc. BTW, I am hoping that once my workload subsides and get some free time I will be able to finally finish FUSE for WSL1:

https://github.com/billziss-gh/winfuse

That would let us run native Linux sshfs on Windows...