Cannot mount using UNC names

andyneff commented 4 years ago

While I can mount using sshfs.exe and sshfs-win.exe, I am unable to use any of the GUI way or net use, which all use the UNC path to mount. What am I doing wrong?

Is it possible that password with special characters (not unicode) don't work?

Version info

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

Problem

net use y: \\sshfs.r\username@computername\tmp or net use y: \\sshfs.r\username@computername
```
The password is invalid for \\sshfs.r\username@computername.

Enter the user name for 'sshfs.r': username
Enter the password for sshfs.r:
System error 67 has occurred.

The network name cannot be found.
```
- I do see sshfs-win.exe, sshfs.exe, and SSHFS's ssh.exe running
- The arguments to sshfs-win svc are exactly when you'd expect them to be.
From "This PC" select "Map Network Drive"
- Enter \\sshfs.r\username@computername or \\sshfs\username@computername\somedir
- Enter username and password
- I do see sshfs-win.exe, sshfs.exe, and SSHFS's ssh.exe running
- The arguments to sshfs-win svc are exactly when you'd expect them to be.
- Eventually I get

Workaround

Use sshfs-win or sshfs from command line

billziss-gh commented 4 years ago

From your description it appears that you are doing things properly and it is not obvious what the problem is. But you seem to be having a lot of problems with SSHFS-Win, which makes me wonder about some deeper problem.

MLXProjects commented 4 years ago

Same error here, just want to mount a remote FS through SSH but can't login (trying to use the same private key which I use to login with PuTTY).

andyneff commented 4 years ago

Here's what I tried to do:

Reformat
Install all windows updates
- No longer insider: 10.0.18363
Install a bunch of software to get computer ready, like Antivirus, git, code editors, etc..
choco install sshfs installs the old 2.7 version, apparently (Which #141 claims helped with the address bar issue in explorer.exe)
- sshfs 2.7.17334
- winfsp 1.6.20027
Reboot
sshfs-win cmd {username}@{computername}:/tmp X:
- Just hangs, nothing happens

I can tell by looking at the ssh server's /var/log/secure messages that no ssh attempts are being made (I'm just starting to monitor this file).

Uninstall sshfs and winfsp and reboot
Download and install latest versions of winfsp and reboot
Download and install latest versions of sshfs and reboot
Try again

Again, the UNC versions so not work.

However, I now see messages in /var/log/messages and /var/log/secure

While my local ~/.ssh/config files (which SSHFS's ssh.exe appears to use when I call it directly) says PreferredAuthentications gssapi-with-mic,hostbased,publickey,password,keyboard-interactive, It appears it is use not using password authentication, but keyboard-interactive (but I could be wrong about this). At any rate, I've verified it is sshing into my destination machine with the right username (which it probably was all along), it's just not getting the right password in... (I have a WSL idea I want to try next... O:-)

Any ideas how I can debug the password that is being sent or see the login interaction of with ssh?

andyneff commented 4 years ago

Ok, So I did a little MITM Python digging, and I've proven to myself that sshfs-win is being run by user: "nt authority\system" with admin privileges, which I was sort of expecting once I knew to ask the question...

I have further proven that as "nt authority\system" with admin privileges, if I use SSHFS's ssh command, it will no longer be using "my" ~/.ssh/config file, but "nt authority\system"'s which does not exist... ("nt authority\system"'s home dir is C:\Windows\system32\config\systemprofile)

As admin, I created an "nt authority\system" command prompt:

PsExec.exe -i -s %SystemRoot%\system32\cmd.exe
whoami - nt authority\system, and I also have admin privileges..
SSHFS's ssh.exe and it was not using my, so was indeed not using "password" authentication mode, like I wanted. This explains why when I read my sshd server's logs, it appear to be failing in keyboard-interactive authentication... because it was!
- As for why It was failing in "keyboard-interactive" mode, I don't know... but I think you'll see that's not the point anymore...

So all I did to fix my problem was to update the registry keys in:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs*
- CommandLine: svc %1 %2 %U -oPreferredAuthentications=password

Unfortunately this particular fix is very specific to me, so not really useful to the community...

However, since %U tells sshfs-win svc the username, It maybe a better solution for all to:

Given the username, ask windows the home dir. It's not always c:\User\{name}, it often has other prefixes/suffixes added. So asking windows the home dir would be important (I'm not actually sure how to do this right, I know python does it wrong, but MINGW bash does it right)
Add -F{home_dir}/.ssh/config
- CommandLine: svc %1 %2 %U -FC:\Users\{hard_code_of_my_homedir}\.ssh\config Worked too!

I think this solution has a lot of flexibility for all, allowing you to edit your config file, and have sshfs-win use that (in svc only, not cmd). Thoughts?

billziss-gh commented 4 years ago

@andyneff the latest beta of WinFsp supports a %P that can be used to get the profile directory of the user. This would make your CommandLine: svc %1 %2 %U -F%P\.ssh\config

andyneff commented 4 years ago

I want to start with: Thank you for all your hard work!!!

This is so VERY close to working... it comes down to quotes. And I will admit, I know glibc quotes like the back of my hand, I have never learned windows quotes, because most of my windows coding is in python, and python args make windows quotes behave exactly like glibc quotes, so I've never had to learn them

I set HKLM\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs*\CommandLine to svc %1 %2 %U -F%P\.ssh\config (exactly)
I went to "Map Network drive", and used \sshfs.r{username}@{hostname}\tmp to Z:, and to my surprise, it fails.
I opened up a "NT Authority/SYSTEM" admin command prompt, and ran:
- sshfs-win.exe svc \sshfs.r\{user}@{hostname}\tmp X: {local_username} -FC:\Users\{username}\.ssh\config
- That worked!
Ok, let's try mounting it a bunch of times, and hope I catch it on Task Manager.
- Wait a minute, there are a quotes around the %P substitution, but that still "looks valid to me", that's can't be it!
I try what would be right, just to make sure I understand quotes some:
- "sshfs-win.exe" svc "\sshfs.r\{user}@{hostname}\tmp" "X:" "{local_username}" -F"C:\Users\andy\.ssh\config"
- That works, good.
Now the way I think sshfs-win is running it:
- "sshfs-win.exe" svc "\sshfs.r\{user}@{hostname}\tmp" "X:" "{local_username}" -F"C:\Users\andy"\.ssh\config
- To my surprise, it failed!:
```
read: Connection reset by peer
KO
```

So it looks like windows wasn't happy with that, if that is indeed the issue, I'm not sure what you would prefer moving forward? Some ideas to spitball:

I hesitate to say "don't add quotes for %P expansion only," and I'll add them in the registry entry because that would create non-uniform behavior, which is your users. But instead what if you have a separate version that didn't have quotes. So %P is quoted, and %p isn't quoted?
- I'm suggesting that in SvcInstanceReplaceArguments, that if the letter is lowercase, FALSE be used instead of Quote
Ummm... Anything else I come up just seems so much worse, like "Make %P behave like a function, so %P(\.ssh\config) expands the right way. I think that add extra complication, but I don't really know what your vision is
Hopefully something far easier I'm missing! :D

billziss-gh commented 4 years ago

I am surprised the quotes around %P do not work. I tried this with a different (non-Cygwin) based file system and I believe they worked. I will have to revisit the quote handling.

andyneff commented 4 years ago

I did my tests in cmd.exe, I thought that best represented WinFSP's environment.

unanwiwo commented 4 years ago

Same problem. Sorry, I made a duplicate #192 I have this problem on my home PC (Win 10 Home) At work everything is OK, I can mount in Windows Explorer (Win 10 Enterprise)

unanwiwo commented 4 years ago

I tried SFTP Drive Personal Free on my Win 10 Home. It works fine...

billziss-gh commented 4 years ago

@andyneff the command line handling bothered me enough that I finally found some time to investigate more.

I believe the problem is that SSHFS-Win is a Cygwin executable and Cygwin's default command line handling differs from the one in Windows.

When you pass:

"sshfs-win.exe" svc "\sshfs.r\{user}@{hostname}\tmp" "X:" "{local_username}" -F"C:\Users\andy"\.ssh\config

Cygwin sees the arguments:

sshfs-win.exe
svc
\sshfs.r\{user}@{hostname}\tmp
X:
{local_username}
-FC:\Users\andy.sshconfig

The fix is to use slash instead of backslash (untested):

svc %1 %2 %U -F%P/.ssh/config

andyneff commented 4 years ago

I will not pretend to fully understand that, but it did indeed work!!!

Thank you for all your hard work!

billziss-gh commented 4 years ago

Glad this worked for you in the end!

ScottNotFound commented 3 years ago

I've encountered a similar problem related to specifying key locations in your config. Changing IdentityFile ~/.ssh/mykey to IdentityFile C:/Users/myuser/.ssh/mykey may fix additional problems for some people. Mapping a network drive with explorer runs the command under the SYSTEM user which can mess up the ~ expansion. This was the case for me, although it didn't use to be a problem. I had this working before but after a windows update (unsure if related) it caused this problem.

Found from running sshfs-win.exe svc ... under SYSTEM.

andyneff commented 3 years ago

@ScottNotFound Using ~myusername/.ssh /id_rsa instead of ~/.ssh /id_rsa in your configure might allow slightly less path coding?

winfsp / sshfs-win