Password-less logins not working, even though they appear to connect successfully

[RoliSoft]

I use private keys instead of passwords to login to my servers. Checking the documentation I could find on sshfs-win, there seems to be no mention of supporting this, however, since I saw the standard ssh.exe and sshfs.exe are bundled, I fired up Process Monitor to see if at any time it tries to read the private keys.

I found that it was trying to access C:\Program Files (x86)\SSHFS-Win\home\SYSTEM\.ssh\id_rsa, so I quickly created a home\SYSTEM directory and copied the appropriate files from my Cygwin installation.

After retrying, I found that it successfully read the private keys, so no privilege issues, however, shortly the Windows error message popped up, informing me that Windows cannot access \\sshfs\root@excelsior.rolisoft.net.

Checking the logs on my server confirms that it was able to connect:

Jul 30 23:01:54 excelsior.rolisoft.net sshd[13532]: Accepted publickey for root from 2a02:2f07:d27c:600:bd86:1e62:fde5:9596 port 30453 ssh2: RSA SHA256:bCkuJouJFMZknUVoW8oCAI/WP/f3dTEaGSWOjCFjE2g
Jul 30 23:01:54 excelsior.rolisoft.net sshd[13532]: pam_unix(sshd:session): session opened for user root by (uid=0)

Running ssh.exe root@excelsior.rolisoft.net from C:\Program Files (x86)\SSHFS-Win\bin as nt authority\system also drops me into a shell, without any password prompts, so it should work.

Going through the whole list of spawned processes during a connect does reveal at least one instance of sshfs.exe exiting with status code 1, however, I'm all out of ideas on how to debug this, as the SSH client has no option to log to a file as far as I know.

[billziss-gh]

SSHFS-Win does not support password-less logins out of the box. The primary reason is that it invokes SSHFS with the options password_stdin (which is a standard SSHFS option that instructs SSHFS to read the password from stdin) and password_stdout (which is a small option I added for the purpose of reporting password authentication success/failure to stdout).

If you are able to rebuild SSHFS-Win you may be able to build your own version that supports password-less logins, by making the following changes:

• Remove the "-opassword_stdin" and "-opassword_stdout" options from sshfs-win.c.
• Change the Credentials registry value to 0 in sshfs-win.wxs.

Unfortunately I expect that simply changing the Credentials registry value to 0 using the registry editor will not work as SSHFS-Win will run SSHFS with the erroneous password_stdin and password_stdout options as stated above.

The Credentials registry value can be found under this key:

HKLM\SYSTEM\CurrentControlSet\Services\WinFsp.Launcher\Services\sshfs

Even nicer would be to modify SSHFS-Win so that it can support both scenarios with registry modifications.

[RoliSoft]

It seems it is not so simple, since I was unable to get it working with your changes.

Furthermore, to debug it, I've added "-oLogLevel=DEBUG3" to SSHFS_ARGS, and the following code right before execle:

FILE* file = fopen("C:\\Program Files (x86)\\SSHFS-Win\\bin\\ssh.log", "a+");
dup2(fileno(file), STDOUT_FILENO);
dup2(fileno(file), STDERR_FILENO);
fclose(file);

With logging turned up to max, and trying to connect to multiple different servers, I've narrowed the issue down to this:

debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug2: subsystem request accepted on channel 0
debug2: channel 0: read<=0 rfd 4 len 0
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
debug2: channel 0: input drain -> closed

Using the "force TTY allocation" options I found for this error didn't do anything.

Have you encountered this error during the development?

[riedel]

works for me when running the original command directly from the (cygwin) commandline without the aforementioned options:
sshfs.exe -ofstypename=SSHFS -o idmap=user -o umask=000 -o Ciphers=aes128-gcm@openssh.com -o Compression=no user@host x:

[blahjig]

Also worked for me using the sshfs-win installer (not a real cygwin environment) by doing the following:

cd "C:\Program Files (x86)\SSHFS-Win\bin"
set CYGFUSE=WinFsp
set PATH=C:\Program Files (x86)\SSHFS-Win\bin;%PATH%
sshfs.exe -ofstypename=SSHFS -o idmap=user -o umask=000 -o Compression=no -o IdentityFile=C:\\Users\\user\\key.openssh user@host:/ x:

I needed to add the SSHFS-Win directory to my path, so sshfs.exe could find ssh.exe

[fire]

This works with ssh https://github.com/cuviper/ssh-pageant ?

[riedel]

This works with ssh https://github.com/cuviper/ssh-pageant ?

Any reason why it should not? I used ssh-agent, ssh-pageant and currently the keepass-sshagent plugin and they all implement the same protocol afaik. Have you tried and failed? As said it all works for me when mounting the sshfs from cygwin with the right Environment. I guess you could also set SSH_AUTH_SOCK globally if you, but i don't know if ssh-pageant supports a fixed sock similar to ssh-agent -a option).

[fire]

I get a

dup() in/out/err failed
read: Connection reset by peer

I'm stuck.

[fire]

$ cd "C:\Program Files (x86)\SSHFS-Win\bin"
$ set CYGFUSE=WinFsp
$ set PATH=C:\Program Files (x86)\SSHFS-Win\bin;%PATH%
$ ssh-pageant.exe
SSH_AUTH_SOCK='/tmp/ssh-Rtr00u/agent.7640'; export SSH_AUTH_SOCK;
SSH_PAGEANT_PID=2372; export SSH_PAGEANT_PID;
echo ssh-pageant pid 2372;
$ set SSH_AUTH_SOCK=/tmp/ssh-Rtr00u/agent.7640
$ sshfs.exe -ofstypename=SSHFS -o idmap=fire -o umask=000 -o Ciphers=aes128-gcm@openssh.com -o Compression=no x@x.x.x.x:/x x:

Works

[fire]

cd "C:\Program Files (x86)\SSHFS-Win\bin"
set CYGFUSE=WinFsp
set PATH=C:\Program Files (x86)\SSHFS-Win\bin;%PATH%
ssh-pageant -a %LOCALAPPDATA%\agent.ssh-pageant
set SSH_AUTH_SOCK=%LOCALAPPDATA%\agent.ssh-pageant
sshfs.exe -ofstypename=SSHFS -o idmap=none -o umask=000 -o Ciphers=aes128-gcm@openssh.com -o Compression=no backup@x.x.x.x:/x x:

Here's a better one. It assumes ssh-pagent in C:\Program Files (x86)\SSHFS-Win\bin.

On reboot only the previous one works. It should be possible to use this logic in the manager and check for ssh-agent, ssh-pageant, keepass-sshagent in the directory.

[xelra]

@riedel I've tried to get this running with KeeAgent, but I simply can't get it to use the socket file. Can you please share how you got it to work (the complete thing with environment and everything)?

My environment is set up correctly, because I can use the ssh command without a problem.

[riedel]

@xelra: I try to just tell you my config. Probably there is simpler/better/safer ways see above

In Options->KeeAgents, I ticked "Create cygwin..." and set it to C:\Users\xxx\AppData\Local\Temp\ssh-agent

thenI set the sock to the same "file":

declare -x SSH_AUTH_SOCK="/tmp/ssh-agent"
(note that /tmp/ maps to C:\Users\xxx\AppData\Local\Temp\ in my config)

I compiled and ran sshfs from cygwin and it worked.

I am a bit puzzled if you say, that KeyAgent worked for you with ssh but not sshfs...

[xelra]

Thank you very much for your response. I have managed to use the socket file by slightly changing the syntax to sshfs -ofstypename=SSHFS user@x.x.x.x:22.

It still errors with read: Connection reset by peer.

On the server I looked at the output of journald and I saw

Oct 02 17:09:21 server sshd[24544]: Accepted publickey for user from x.x.x.x port 52835 ssh2: ED25519 SHA256:<secret>
Oct 02 17:09:21 server sshd[24544]: pam_unix(sshd:session): session opened for user user by (uid=0)
Oct 02 17:09:21 server systemd-logind[387]: New session c21 of user user.
-- Subject: A new session c21 has been created for user user
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: https://www.freedesktop.org/wiki/Software/systemd/multiseat
--
-- A new session with the ID c21 has been created for the user user.
--
-- The leading process of the session is 24544.
Oct 02 17:09:21 server systemd[1]: Started Session c21 of user user.
-- Subject: Unit session-c21.scope has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit session-c21.scope has finished starting up.
--
-- The start-up result is done.
Oct 02 17:09:21 server sshd[24544]: pam_unix(sshd:session): session closed for user user
Oct 02 17:09:21 server systemd-logind[387]: Removed session c21.
-- Subject: Session c21 has been terminated
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: https://www.freedesktop.org/wiki/Software/systemd/multiseat
--
-- A session with the ID c21 has been terminated.

That confirms that the connection and authentication is successful, but then it gets terminated. Does anyone have any idea what could be wrong?

[xelra]

After spending 2 days of trial and error, I found an acceptable way of using SSHFS-Win. I couldn't get it to run inside of Cygwin at all, because it would always terminate itself after authentication as described in my last comment.
That doesn't matter though, because running it inside the Windows environment is the goal anyway.

I'm sharing my way of starting and killing the mounts in this other issue: #15.

@riedel Thank you for your help.

[yanivhamo]

I managed to get it to work with Map Network Drive using a private ssh key and without password prompt.

@RoliSoft, I basically did what you reported back in July 2016, only instead of compiling sshfs-win from source, I simply hex-edited sshfs-win.exe (life is too short for compiling). Initially I replaced -opassword_stdin and -opassword_stdout with spaces, but that didn't work. Launching sshfs from the command line with quoted spaces indeed resulted in an error. So instead of spaces, I just replaced them with two harmless parameters (well, harmless in my case); I changed -opassword_stdin to -oidmap=none (space padded), and -opassword_stdout to -oworkaround=none.

I changed the registry value HKLM\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs\Credentials to 0 as per @billziss-gh suggestion.

Then I put my private SSH key (id_rsa) in C:\Program Files (x86)\SSHFS-Win\home\SYSTEM\.ssh and made sure to remove all permissions from it, then changed the owner to SYSTEM (otherwise Cygwin's ssh complains that the permissions on the key file are too open and croaks).

At this point, Map Network Drive works, for connection strings of the format \\sshfs\user@host. But I wanted to mount the server's root folder '/', and not the user's home dir. \\sshfs\user@host:/ which works from the command line, does NOT work from Map Network Drive nor via net use. After pulling a couple of the few hairs I have left, I realized that it's the colon; Windows doesn't like it. Scanning through the code in sshfs-win.c reveals (line 78) that the host string is read until either the connection string ends, or '/' is encountered, and then the path is set to whatever follows that '/'. That gives the solution: if you want to mount the root folder on your server, use \\sshfs\user@host//; the double slash at the end is the trick.

@billziss-gh Thank you for this beautifully written software suite, it has directly increased the productivity of many people!

[billziss-gh]

@yanivhamo excellent work at putting all the pieces together on your own :)

[fire]

Is it possible to support both password + key login in the released version?

[ghost]

@billziss-gh is it possible support pub key login?

[xelra]

@netroby I described how I did it here #15 (comment).

There's no UI for it, but it's not the most complicated thing in the world either.

[fcying]

work fine with cmd and original sshfs-win and ssh-config

mount

set "PATH=D:\Program Files\SSHFS-Win\bin;%PATH%"
sshfs.exe -o idmap=user lin:/home s:

unmount

taskkill /im sshfs.exe /f

ssh-config: D:\Program Files\SSHFS-Win\home\fcying\.ssh\config

StrictHostKeyChecking no
Host lin
    HostName 192.168.x.x
    User fcying
    port 2222
    IdentityFile ~/.ssh/id_lin

[ctaggart]

I've spent several hours on this and each time it results in read: Connection reset by peer. It feels like a blinking red light that I don't know how to troubleshoot.

[xelra]

@ctaggart Without knowing any of the specific details, my first guess is that you're having troubles with cygwin. You're probably modifying files or changing environment variables for the wrong cygwin installation.

sshfs-win comes with its own cygwin install and you have to target that one specifically with the things that are mentioned in this issue.

[billziss-gh]

@tsauri thanks for the write up.

BTW, the latest SSHFS-Win beta sets up the Cygwin environment in such a way that the ~/.ssh/id_rsa folder lives in the Windows user's home directory (i.e. \Users\USERNAME\.ssh). This should make things simpler and more secure.

[ghost]

Great works

[ghost]

I tried the beta sshfs-win, it still ask for password. But my ssh only login via public key.

[ghost]

The same : read: Connection reset by peer

[billziss-gh]

@netroby which method did you try for SSHFS-Win beta?

• Map network drive from Explorer?
• Command line invocation of sshfs.exe?
• SiriKali?

[ghost]

both of them.all failed ⁣发自 BlueMail ​ 2018年8月30日 下午12:47, 下午12:47，在 Bill Zissimopoulos <notifications@github.com> 已写:

…

@netroby which method did you try for SSHFS-Win beta? - Map network drive from Explorer? - Command line invocation of `sshfs.exe`? - SiriKali? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1 (comment)

[billziss-gh]

@tsauri you are welcome :)

[ghost]

Hi @billziss-gh and @yanivhamo ,
I try to use sshfs in password-less (then changing -opassword_stdout and -opassword_stdin) but it's seems impossible to rebuild the project with "make" maybe I'm doing it badly ?

Why am I doing this:
I want to use docker-machine and create a shared folder between windows and docker-machine hyperv VM. docker-machine mount need sshfs to work. The problem here is that sshfs ask me to login with a password to connect... I want sshfs to find my private key to connect automatically.

Thanks for your work!

[4O4]

@yatsukino you might want o look at #41

[ghost]

@4O4 thank to you I succeeded to build but it's still not working... I have the following error :

read: Connection reset by peer
exit status 1

Maybe the private key is in the wrong place ?

[4O4]

@yatsukino Can you describe how exactly are you doing this? Are you trying one of the approach described in the comments above? AFAIR this one worked for me before: #1 (comment)

[ghost]

@4O4 I downloaded the source code then replace -opassword_stdin to -oidmap=none, and -opassword_stdout to -oworkaround=none (I've tried to delete them, but same result) as explained by @yanivhamo. I also changed the value of the credential to 0 and I build the project with your help. Before installing my new build I've removed the previous version of sshfs.

About your comment link I've just tried this but same it return me Connection reset by peer ...
( I've tried this command sshfs.exe -o idmap=user test:/home V1 test is my docker machine name and V1 is an empty volume)

Hope I did not forget information.

[kckemper]

@tsauri thanks for the write up.

BTW, the latest SSHFS-Win beta sets up the Cygwin environment in such a way that the ~/.ssh/id_rsa folder lives in the Windows user's home directory (i.e. \Users\USERNAME\.ssh). This should make things simpler and more secure.

Is there any documentation for this? I placed my key files into the .ssh directory (like I would in linux) and it doesn't seem to use them - it still pops up the password dialog box. I need to access a server that doesn't allow password logins.

I'm using v3.2.18213

[stevenguh]

I took me a while but I finally able to get it to mount with IdentityFile. If you like UI and a system tray icon, I suggest you to use SiriKali. I started using SiriKali because I couldn't figure out how to make sshfs work with identity file.

Here is how I am able to identity file with sshfs-win. I am using SSHFS-Win 3.5 BETA and Windows 10 to start with.

1. Launch cmd.exe
2. Enter and execute "C:\Program Files\SSHFS-Win\bin\sshfs-win.exe" svc \sshfs\<remote-user-id>@<remote-ip>\ <DriveLetter>: <DomainName/username> "-o idmap=user,StrictHostKeyChecking=no,ServerAliveInterval=60,IdentityFile=C:/<path-to-your-key>/key.pem"
3. Press an extra enter key for some reason
4. Press Control-C to unmount

The key here is the use of StrictHostKeyChecking=no. I kept getting connection reset error without this setting.
ServerAliveInterval=60 is an option of ssh to keep the the connection alive by sending null packet. I like to keep this option because some servers I connect to have a relative low ClientAliveInterval. The mount will automatically unmount if the timeout has reach.

[Scanerrr]

Hi thanks it works
Trying to automate it, any idea how to skip enter key?
> 3. Press an extra enter key for some reason

Or maybe is there a way to mount it permanently?

[temintyd]

I almost got this working.

Using:

• Windows 10
• WinFsp 1.4.19049
• SSHFS-Win 3.5.19178 x64 (recompiled installer with sshfs_2.x instead of sshfs3 because of error 0x800703E3: Extremely poor performance with latest stable, I/O error, random crashes on folder creation #54 (comment)

Configuration

• added C:\Program Files\SSHFS-Win\bin to Windows PATH
• created C:\Users\Username\.ssh\config

Host servername
    HostName servername
    IdentityFile ~/.ssh/servername_id_rsa
    StrictHostKeyChecking no

• copied private key to C:\Users\Username\.ssh\servername_id_rsa
• changed persmissions on C:\Users\Username\.ssh\servername_id_rsa (disable inheritance and remove other permissions, and set full control to current user)

Mounting using command line works:
sshfs-win.exe svc \sshfs\username@servername X: username -ofollow_symlinks -otransform_symlinks -ocreate_umask=000

Mounting using "Map Network Drive" doesn't:

• First set registry key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs\Credentials to 0
• Computer -> Map Network Drive -> \\sshfs\username@servername
• Explorer does not ask for password: OK
• Error "Windows cannot access .."

@Scanerrr

Trying to automate it, any idea how to skip enter key?

Use "echo & echo.|sshfs-win.exe ..." to simulate ENTER key

[temintyd]

Now I got it working using a recompiled version of SSHFS-Win 2.7 (removing "-opassword_stdin", "-opassword_stdout" and adding -ofollow_symlinks -otransform_symlinks -ocreate_umask=000 to sshfs-win.c), setting Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs\Credentials to 0 and creating C:\Program Files (x86)\SSHFS-Win\home\SYSTEM.ssh\id_rsa

But it would be better to have the key in the user home folder.

[dcourcel]

SSHFS-Win does not support password-less logins out of the box. The primary reason is that it invokes SSHFS with the options password_stdin (which is a standard SSHFS option that instructs SSHFS to read the password from stdin) and password_stdout (which is a small option I added for the purpose of reporting password authentication success/failure to stdout).

If you are able to rebuild SSHFS-Win you may be able to build your own version that supports password-less logins, by making the following changes:

* Remove the `"-opassword_stdin"` and `"-opassword_stdout"` options from sshfs-win.c.

* Change the `Credentials` registry value to `0` in sshfs-win.wxs.

Unfortunately I expect that simply changing the Credentials registry value to 0 using the registry editor will not work as SSHFS-Win will run SSHFS with the erroneous password_stdin and password_stdout options as stated above.

The Credentials registry value can be found under this key:

HKLM\SYSTEM\CurrentControlSet\Services\WinFsp.Launcher\Services\sshfs

Even nicer would be to modify SSHFS-Win so that it can support both scenarios with registry modifications.

Hi @billziss-gh ,
I want to thank you first of all for this software. I find it very usefull!

I have a suggestion of an implementation to support both scenarios. I can't create a branch to create a pull request, so I attached a patch file that can be applied from the git tag v3.5.19106.

The principle is that I read the registry key and, if it is 0, I send the parameter -oIdentityFile pointing to c:/Users/<username>/.ssh/id_rsa, where <username> correspond to the variable locuser_nodom, othewise I pass -opassword_stdin and -opassword_stdout to sshfs. I noticed with the last version that if I launch sshfs-win from the command line with my user, the -oIdentityFile would not be needed because it finds my key to connect. The reason why I add -oIdentityFile in the patch is to make it works when mounting the drive from Windows Explorer because the process sshfs-win is executed as System user and it doesn't find the key in this situation.

authenticateWithSSHKey.patch.txt

[billziss-gh]

@dcourcel thanks for the patch.

I can't create a branch to create a pull request, so I attached a patch file that can be applied from the git tag v3.5.19106.

Creating a PR (Pull Request) on GitHub is quite easy. In the most basic scenario you just fork the project, apply your changes to your fork and then create a PR from these changes. This would allow me to properly review your patch, suggest changes, attribute the code to you when it is merged in, etc.

The principle is that I read the registry key and, if it is 0, I send the parameter -oIdentityFile pointing to c:/Users//.ssh/id_rsa

I read your description above and read your patch.

I like the general idea. But IMO a better approach would be to introduce a new prefix (e.g. \\sshfs.key\...) which does key authentication. Then your mustUseSSHKey function checks to see if the supplied "class name" (contained in the cls variable) has the Credentials registry setting or not.

The reason why I add -oIdentityFile in the patch is to make it works when mounting the drive from Windows Explorer because the process sshfs-win is executed as System user and it doesn't find the key in this situation.

Fair enough! But we should not hard code the C:\Users path, but instead use getpwnam (which sshfs-win.c already uses) to get the user's home directory. See man getpwnam.

---

Please consider resending this as a PR if possible.

[dcourcel]

PR #129 is created! I don't write in C often (Too low level for me ;) ), so feel free to tell me everything that is incorrect in my code.

[billziss-gh]

Thanks to @dcourcel's PR, which has been merged in, SSHFS-Win now supports public key authentication out of the box. We can therefore close this issue.

I will be publishing new SSHFS-Win binaries with this enhancement soon.

[ghost]

Great works. thanks for @dcourcel

[dcourcel]

It was a pleasure!

[mstrap]

@dcourcel I'm trying to figure out a way to use custom, password-protected public key files. Is this something which should be possible with this patch?

[dcourcel]

To use a private ssh key file protected by a passphrase, you can do it with the command line, but not from the Windows file explorer. In the command prompt, you can enter "C:\Program Files\SSHFS-Win\bin\sshfs-win.exe" cmd <username>@<server address>: <letter drive>: and it will be mounted as a local drive or you can enter "C:\Program Files\SSHFS-Win\bin\sshfs-win.exe" svc \sshfs.k\<username>@<server address> <letter drive>: "<Your Windows username>" and it will be mounted as a network drive. In both cases, it will ask you for the passphrase of the key. Note that <Your Windows username> is the username of your windows account.

I am not sure it would be easy to make it work with Windows file explorer. The idea I have is to use Windows popup asking for username and password to get the passphrase, but I don't know exactly how the information from Windows popup is transfered to sshfs-win.exe. I think this part is handled by WinFsp service that use registry key to know if it must show the Windows popup or not. Even if sshfs-win.exe receives the passphrase by stdin or from another way, I don't know how to transfer the passphrase to sshfs. sshfs process launches ssh process and it is ssh process who asks for the passphrase in the command prompt. The process sshfs have the option -opassword_stdin for an authentication using a password, but for a passphrase for ssh key, I don't think there is such option.

[mstrap]

@dcourcel, thanks for this detailed information which was really helpful to get public key authentication working for me. Using sshfs-win.exe is fine for me. I ended up with following command line:

"C:\Program Files\SSHFS-Win\bin\sshfs-win.exe" svc \sshfs.k\user@server x: "foobar" "-oIdentityFile=c:/keys/private.key"

On the way to this final command line, I noticed the following:

• the username does not matter for me, hence I'm using foobar, however it must be present, otherwise the subsequent "-oIdentityFile=..." will not be interpreted as parameters
• for "-oIdentityFile=...", it's important to use no space between -o and IdentityFile despite what many other examples show
• regarding the prefix, it matters whether the path has a trailing \\ or not. If the server's root directory can be accessed, it seems to be a good idea to use \\ because this ensures that absolute symlinks will be resolved correctly (otherwise they will be resolved against your home directory which usually gives invalid paths).
• for one of my servers, my access is limited to only my home directory. Hence, no \\ must be used. Otherwise access is not possible at all. Also, using the absolute path to my home directory does not work here.

[Ilanfigueiredo]

I did all the steps @yanivhamo mentioned and finally managed to connect to the server with the private key (thanks for the help). However, unfortunately I was unable to mount the root folder on the server (the double slash trick at the end didn't work for me). For example: \\sshfs\user@host//scratch/path.

Would anyone know what I did wrong or even another tip to make the connection not from the home directory?

[Ilanfigueiredo]

Thanks to @dcourcel's PR, which has been merged in, SSHFS-Win now supports public key authentication out of the box. We can therefore close this issue.

I will be publishing new SSHFS-Win binaries with this enhancement soon.

@billziss-gh

Thank you for developing and publishing the software. I wonder if there would be any predictions for publishing the new SSHFS-Win binaries (sorry for the question). Thanks again for the contributions.

[billziss-gh]

@Ilanfigueiredo it is my understanding that public key cryptography now works out of the box. Just download the latest release, place your keys in %USERPROFILE%\.ssh\id_rsa and use the syntax \\sshfs.k\USER@HOST when launching the file system.

See the README.

[Ilanfigueiredo]

@Ilanfigueiredo it is my understanding that public key cryptography now works out of the box. Just download the latest release, place your keys in %USERPROFILE%\.ssh\id_rsa and use the syntax \\sshfs.k\USER@HOST when launching the file system.

See the README.

Thank you @billziss-gh, it worked just fine.

About the mount the root folder on the server, I tried the double slash as @yanivhamo did (e.g. \\sshfs\user@host//), but it did not work for me, even using the syntax \\sshfs.k\USER@HOS

Thank you again

[yanivhamo]

Thank you @billziss-gh, it worked just fine.

About the mount the root folder on the server, I tried the double slash as @yanivhamo did (e.g. \\sshfs\user@host//), but it did not work for me, even using the syntax \\sshfs.k\USER@HOS

I just looked at the new documentation, and there is this:
\\sshfs.r\[LOCUSER=]REMUSER@HOST[!PORT][\PATH]
"The sshfs.r prefix maps to HOST:/PATH on the SSHFS host (i.e. relative to the HOST's root directory)."

Did you try that?

I am still using the old version, with the // trick, works great for me. Could it be a permissions issue on your root folder?