Workarounds for getting private key access to remote host file systems using SSHFS-Win with Windows Explorer

[fphartnc]

I've seen a lot of people trying to coax SSHFS-Win into working with SSH config files, mostly with the intent of being able to use pre-configured private key files for remote logins. I'm in that same quandary myself, and I've hit upon a few workarounds that might benefit others and want to pass along what I've discovered. These are not source code fixes for anything, but a set of configuration workarounds that might be useful.

1.) SSH config files: To paraphrase Obiwan Kenobi, Use the symlink, Luke! Duplicating C:\Program Files\SSHFS-Win\etc\ssh_config with the contents of ~/.ssh/config is a waste of time. Worse, some people here have noted that their IT departments have the Program Files folder locked down. The fix is to make sshfs-win use your ~/.ssh/config file by creating a symlink in Windows. If you can't do this yourself, then your IT people will bothered only one time to run this command, and you can take it from there by modifying the ~/.ssh/config file to your heart's content. First, open a Windows Command Prompt (as Administrator) and navigate to the folder C:\Program Files\SSHFS-win\etc and then run this command:

mklink ssh_config C:\Users\<username>\.ssh\config

where <username> is your Windows login. Now when the ssh.exe and sshfs-win programs in C:\Program Files\SSHFS-Win\bin are executed, the symlink will cause the contents of your OpenSSH config file ~.ssh\config to be referenced instead. [Symlinks have existed in the *nix world forever, but have only been available in Windows since W10 and W11. They're not available in earlier versions of Windows. I am using Windows 10.]

2.) Use the complete file path in your SSH config file IdentityFile directives: Unfortunately, there's no way around this. I attempted to map network drives with the IdentityFile directive set to both ~/.ssh/<id_file> and C:/Users/<username>/.ssh/<id_file> and only the latter way worked. So you'll have to go back into your ~/.ssh/config file and make those changes. [The underlying issue here is probably that ~ is a relative file indicator, and when crossing from a symlink the value of that is probably defined to be something like C:\Program Files\SSHFS-Win\bin... so it would fail.] However, I can categorically state that one is not confined to using "id_rsa" or the like for the identity file name; any valid private key formatted file in ~/.ssh will work.

Now, just for completeness here, I'll note that I also include the following directives in my ~/.ssh/config file for each Host: HostName (IP address in my case; I imagine an FQDN would work but haven't tried it yet), User <user>, Port <port>, and IdentitiesOnly yes... along with the full-path to the IdentityFile as discussed in the previous paragraph.

3.) You must still include the <User> and <Port> defined in your config file in your drive mapping in Windows! So the value you're getting here is the ability to connect with those private keys. Sorry about that, but this appears to be a problem with some combination of the code in sshfs-win and winfsp. So the syntax to put into the Folder field of the Map Network Drive dialog box looks like this:

\\sshfs.kr\<User>@<Host>!<Port>

where the items inside the <> exactly correspond to the directive fields for the Host in your ~/.ssh/config file. [And of course, I'm encapsulating those directives inside the <>, so don't include them -- include only the content of the directives from the config file.]

Observations:
1.) I validated that ssh.exe in C:\Program Files\SSHFS-Win\bin worked with the symlink before doing anything else. Here, believe it or not, the ssh.exe program worked with the IdentityFile directive containing the ~ but then I later found that sshfs-win.exe did not work when driven by the "Map Network Drive" GUI, but it isn't clear whether the issue is in sshfs-win.exe or the FSP itself. Just know that you must use the complete file path to get a workable drive mapping using the Windows GUI.
2.) I also validated that the OpenSSH client in Windows would be unaffected by using the full (and not relative) path in the IdentityFile directive. To do this, I ran ssh -v <HostName> in PowerShell, and it worked with both the relative and full paths.
3.) For my testing, the target host was a router running OpenWrt, and the connection was made to a WAN (not LAN) port running an OpenSSH (not dropbear) server, with the OpenSSH server configured only to accept passkeys.
4.) Versions I am using (since YMMV): SSHFS-Win -- 3.7.21011, WinFsp -- 2.0.23075, Windows: 10 Pro 2H22.

[jasonhillva]

Bro you just solved a problem I've been banging my had about for the last 1.5 hours. Thank you so much and this info needs to be in their freaking readme. Let's get that read me fixed folks!