Mounting and unmounting too complicated about sshfs-win

[Iznakurnog]

SSHFS-WIN-SCRIPTS.zip
Inspired by ideas of this thread I write my own small set of powershell scripts.
They are simple to use and even more convenient for me than GUI could be
I make shortcuts for them and use to mount and unmount disks whenever I need.
Usage :
unmount_disk.ps1 - interactive script to unmount all or particular drive (by letter)
Mount_disk_H(example).ps1 - this script is template to create profiles for every disk we are going to mount.
It is actually list of parameters for sshfs-win - disk letter, remote server name , options etc
and after all parameters are defined it calls main script Start_sshfs-win_main.ps1
which start sshfs-win as hidden process. Most tricky part here was to preserve output of hidden sshfs-win
for debugging of possible connection issues. But after some R&D I managed to solve it.
Copies may be named Mount_disk_Y etc to easely understand what we are mounting ...

Restrictions - I use only password authentication and do not want to store password so I just type them interactively on prompt
Surely script can be easily tuned to use KeeAgent or even somebody may want to hardcode pass.

Hope will be useful for many so I gladly share the solution.

P.S. sshfs-win really great tool and is always 2-4 times faster than SFTP Net Drive .
I use it for read only access currently (that is actually what I need most)
because I have 0-length files issue too : #11

[billziss-gh]

@xelra thank you for your suggestions. I think it is time to devote some more time on SSHFS-Win and improve it.

SSHFS-Win was created as more or less a demo file system for WinFsp-FUSE. The scenario I wanted to enable was fairly simple: use the Explorer or the command-line to easily mount an SFTP service. I chose to support username/password authentication because it easily fit the "Map network drive" model.

However I recognize that most professionals using SSH prefer to use private keys, especially in enterprise scenarios (I did so myself in a previous lifetime). The question is how to allow such usage in a clean fashion. Using the Windows "map network drive" functionality is still my preferred approach. I would have to devote some time to (again) fully understand all the authentication mechanisms that SSH provides and see how to map them to the Windows "map network drive" model (if indeed they can be mapped).

I am happy to work with you or anyone else that has such knowledge in order to make SSHFS-Win better.

---

A few words about the SSHFS-Win environment that may help shed some light on some of the issues encountered:

• SSHFS is a Cygwin program that runs inside its own Cygwin environment. This means that it will not interfere with an existing Cygwin installation.

• The Cygwin environment that ships with SSHFS-Win is truly minimal and includes only the minimum amount of programs required to have it run.

• The Cygwin environment uses as its root the Windows directory \Program Files (x86)\SSHFS-Win (in a 64-bit installation). This means that directories like /home do not exist unless you create a home subdirectory under the SSHFS-Win installation directory (for example, you can place there your known_hosts file).

• Under normal usage (i.e. when run through the Windows Explorer or through the net use command), SSHFS-Win runs under the direction of a special Windows service called WinFsp.Launcher. This service looks in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs and determines how to start SSHFS-Win.

• Under normal usage SSHFS-Win runs under the Windows SYSTEM account. Drives created by the SYSTEM account are visible to all users in Windows.

[mhogomchungu]

Sorry for a long delay,i was on the road and didnt have access to the internet.

I have no problem supporting it and will look into it.

[mhogomchungu]

I think i am done implementing support for sshfs on both linux and windows and windows.

Windowa users should reinstall SiriKali using the installer provided in the project's main page to get the functionality.

Instructions on how to add options to sshfs backend are explained here[1].

[1] mhogomchungu/sirikali#61 (comment)

[xelra]

To my knowledge there are 3 ways of auth in SSH. The first one is by password, the second one is by private key and the third one is via an agent that provides an already loaded private key via a socket file.

Almost any user I know uses private keys and every security guide I know urges people to completely deactivate password logins after initially setting up a server and also encrypting the private key. Personally I have passwords as well as root logins deactivated.
Because handling keys can be quite tedious most professional users use an agent. For Windows users I recommend KeePass and its plugin KeeAgent. It will make the agent available via a socket file that ssh.exe can load through the SSH_AUTH_SOCK environment variable. The great thing about this agent is that you can store the keys as well as the passwords for the key's encryption inside of the KeePass password manager. That means that as soon as your KeePass wallet is unlocked, you are ready to go without any further input.

The way I'd like to use SSHFS-Win is via a system tray icon that opens a UI where you can mount and unmount remotes. I think it should work like this:

• At first start the interface is empty.
• Then you click a "add remote" button and configure a remote.
• In the configure screen you should be able to set all the ssh parameters as well as the method of authentication.
• Back at the main screen you can now click the remote from a list and hit either mount/unmount button.

Now if a user wants to mount directly via the file explorer he can still do that. By entering \\sshfs\[email protected] he loads an un-preconfigured remote just like it is now. But by going to a known and preconfigured remote via this method or by using a remote name like \\sshfs\preconfiguredRemoteName it is using the special settings and methods of authentication for that remote.

I think this method is pretty versatile and fool-proof and also retains the features of the current implementation.

@billziss-gh I'm very glad that you're interested in making SSHFS-Win into an easily usable Windows application. The state of FUSE and SSHFS on Windows has been very poor for many years and always pressured me into very uncomfortable compromises in my workflow.

[billziss-gh]

I like your ideas on how to configure/control SSHFS-Win.

OTOH I find that a system tray app would probably be best as a separate project. I would like to keep SSHFS-Win a simple project, but still flexible enough to support the configuration scenarios you describe.

One of the main challenges is that SSHFS-Win is run under the SYSTEM account (at least when you do "map network drive"). This has a few implications:

• A file system mounted by one user is now available to all users on that machine. This is not generally a problem, because true multi-user scenarios are rare these days (at least on Windows computers).

• SSHFS-Win has no notion of "current user" or "user who started the file system" and it is therefore not straight-forward to pass/find configuration information for that user.

I see a few different approaches:

• Currently SSHFS-Win supports only password authentication. This is done by presenting a password prompt in the desktop of the user who is doing "map network drive". [The password can be stored in the user's "credentials manager", so that no additional prompts are necessary.] The password is then passed to SSHFS-Win through a named pipe.

  • This mechanism could be extended to support authentication mechanisms other than password. It is not clear to me if this is easily possible or straightforward.

• Additional authentication mechanisms can be supported by configuring the SSHFS-Win environment for the SYSTEM account. SSHFS-Win runs inside a minimal Cygwin environment that has no home directories. If one creates a home\SYSTEM directory under the SSHFS-Win installation directory, SSHFS (and SSH) will find it and honor any files in it (e.g. known_hosts). Cygwin allows us to place home directories in a more convenient location (e.g. \ProgramData\SSHFS-Win) and we could use such a location for configuration purposes.

• Run the file system under the "current user" account rather than the SYSTEM account. This is an obvious approach that would allow flexibility in supporting different configuration scenarios. It can however have problems on Windows. The main issue is that of the "drive namespace". In Windows "drives" (C: D: X:, etc.) are only visible to the user that created them. Even worse a drive that is created by a user while they are not elevated to have administrator privileges, is not visible to the same user when they are elevated! The SYSTEM account does not suffer from any such problems as drives added by the SYSTEM account are visible to everyone on the system.

---

Lastly, while I am happy to support an SSHFS-Win configuration app (like the system tray icon app you describe), I am probably not the right person to work on it at this time. @xelra would you be interested to work on something like this? I would happily support such an effort.

[xelra]

I've given this some more thought and I think you're right, the app should stick to Unix paradigms and not mix logic with UI.

I think a good approach would be to expose the above talked properties in a .ini or a .config file, where one could configure a remote. If anyone ever wants to make a UI, then all it would need to do is edit the config file.

Maybe something like

[remoteName1]
address=x.x.x.x
port=12345
user=
authSocket=agent.socket
umask=022
create_umask=022
idmap=user

[remoteName2]
...

That would already have all the features for configuring remotes. Those could be mounted with the explorer method.

The only thing that wouldn't be possible, is mounting and unmounting visually.

Maybe making sshfs.exe accept the configured remotename would help with that. Then everyone could make simple shortcuts. Something like

SSHFS-Win\bin\sshfs.exe remoteName1 X:
SSHFS-Win\bin\sshfs.exe [email protected]:12345 X:

So that both of these methods would try pulling in the config.

[billziss-gh]

@mhogomchungu is the author of SiriKali which is a frontend to various file systems including securefs, which is a cross-platform file system that uses WinFsp on Windows. He is working on adding SiriKali support for securefs and WinFsp: winfsp/winfsp#121

I am wondering if SiriKali could act as the UI that controls SSHFS-Win (assuming that you have the time and interest of course @mhogomchungu).

[mhogomchungu]

I can not figure out how to run sshfs-win from the terminal and the two examples posted here have so far proved to be beyond my comprehension.

Connecting to the remote system using window's explorer works fine and i am not sure why people want alternative to it,

I think this project needs to be documented better if it is meant to be used by others.

[xelra]

@mhogomchungu The reason why the explorer method isn't enough is that it doesn't expose any options.

I'm starting my connections with this line:

start /B cmd /C "set "SSH_AUTH_SOCK=C:\msys64\home\xelra\.ssh\KeeAgent.socket" && set "CYGFUSE=WinFsp" && set "PATH=C:\Program Files (x86)\SSHFS-Win\bin;%PATH%" && "C:\Program Files (x86)\SSHFS-Win\bin\sshfs.exe" -o idmap=user -o StrictHostKeyChecking=no [email protected]: X:"

This sets the environment for the cygwin installation that comes with sshfs-win and it also exposes the SSH_AUTH_SOCK variable to sshfs.exe, which points to my ssh-agent. Also as you can see, I have some options set. That connection only uses key authentication. No passwords.

[mhogomchungu]

How is C:\msys64\home\xelra\.ssh\KeeAgent.socket path constructed?

I guess i am really asking is xelra part the name of a logged in user?

[billziss-gh]

@xelra BTW, the CYGFUSE=WinFsp environment variable is no longer needed with latest version of SSHFS-Win (but it does not hurt either).

Carry on :-)

[mhogomchungu]

Support for sshfs-win backend in SiriKali will be tracked here: mhogomchungu/sirikali#61

[xelra]

@mhogomchungu That's simply the path to the socket file. In KeeAgent in KeePass I simply specify this as the path where the socket file is. It could be somewhere else.
The reason I put it there is because that's the Cygwin directory of my MSYS2 installation C:\msys64. I'm using the same agent in my msys terminal to connect to my servers via OpenSSH.
And yes, xelra is the Windows user. In Cygwin, each Windows user gets his home directory in <installDir>\home\<user>.

sshfs-win also has its own cygwin install, which is why there's also C:\Program Files (x86)\SSHFS-Win\home\xelra\.ssh\known_hosts.
For a system-wide mount this could also for example be in C:\Program Files (x86)\SSHFS-Win\home\SYSTEM\.ssh\known_hosts.
I'm using the first one and mount in user space. There are benefits as well as caveats to mounting user- or system-wide, which we talked about further up.

[mhogomchungu]

git version of SiriKali now supports sshfs on linux. I will have access to my windows computer this weekend and i will work on the windows port then.

This socket path, will SiriKali have to set it manually or can SiriKali assume it to already be present and sshfs will pick it up if SiriKali just copies the current environment and pass it along to sshfs?

Instructions on how to set up sshfs options are on mentioned SiriKali bug report.

[xelra]

@mhogomchungu The socket path will have to be configurable and injected into the environment, because it is user defined and different for everyone, depending on what agent you're using and how you set it up in general.

EDIT:
In my third post, there was this idea of having a settings file to configure remotes, which could also be used via the explorer mount option. This would need to be a sshfs-win feature though, which SiriKali could make use of after the fact.