Use PuTTY Pageant (or KiTTY Kageant) for encrypted SSH keys

[bersbersbers]

This started months ago at #217 (comment), and I have finally found the core issue and a potential solution (as well as a workaround, see next comment).

Get ssh-pageant.exe, e.g., from https://github.com/cuviper/ssh-pageant/releases/tag/v1.4-prebuilt-cygwin64.

I got mine, version 1.4, from Cygwin:
https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fssh-pageant%2Fssh-pageant-1.4-1&grep=ssh-pageant

Launch PuTTY's pageant or KiTTY's kageant and load your key(s). Then, start ssh-pageant like this:

set SSH_AUTH_SOCK=%TEMP%\ssh-pageant.socket
ssh-pageant.exe -r -a %SSH_AUTH_SOCK%

Ideally, this should be it - fire up sshfs-win.exe from a shell where SSH_AUTH_SOCK is set correctly (you can use setx SSH_AUTH_SOCK %TEMP%\ssh-pageant.socket once to set it globally once and forever, and auto-start ssh-pageant.exe on login) and you should be good.

Unfortunately, it seems that the value of SSH_AUTH_SOCK is lost when sshfs-win.exe calls ssh.exe through sshfs.exe. I suspect the problem to be here:
https://github.com/billziss-gh/sshfs-win/blob/bb6c90d35cfb309cf976794a7f12938f1ebee136/sshfs-win.c#L248

(Note: sshfs usesexecvp(sshfs.ssh_args.argv[0], sshfs.ssh_args.argv) instead, see https://github.com/libfuse/sshfs/blob/9e01ffd161591f87dd7ef02ab2a0f0aecd800a00/sshfs.c#L1225,
which does not have this problem as we will see.)

[bersbersbers]

As a workaround for the issue above, translate your call of sshfs-win.exe to one using sshfs.exe. In my case, I went from

"C:\Program Files\SSHFS-Win\bin\sshfs-win.exe" svc \sshfs.kr\bers@host\/ W: bers -d -o ssh_command=bin/ssh.exe -o umask=000 -o create_file_umask=133 -o create_dir_umask=022 -o loglevel=debug3

to the equivalent

"C:\Program Files\SSHFS-Win\bin\sshfs.exe" bers@host:/ W: -d -o ssh_command=bin/ssh.exe -o umask=000 -o create_file_umask=133 -o create_dir_umask=022 -o loglevel=debug3

That's it!

[billziss-gh]

@bersbersbers

Thank you for working on this and figuring out a solution.

The reason that sshfs-win.c uses execve rather than execvp is to pass a clean environment to sshfs.exe. The primary reason is that we want to set up our own PATH environment variable and not simply use the one from Windows.

Perhaps a better approach would be to copy the environment from Windows and just overwrite PATH. What do you think?

[bersbersbers]

@billziss-gh

Thank you for working on this and figuring out a solution.

You're welcome!

The reason that sshfs-win.c uses execve rather than execvp is to pass a clean environment to sshfs.exe. The primary reason is that we want to set up our own PATH environment variable and not simply use the one from Windows.

I see - this will be this, I guess:

https://github.com/billziss-gh/sshfs-win/blob/bb6c90d35cfb309cf976794a7f12938f1ebee136/sshfs-win.c#L23

But is that working, though? What we discuss around #95 (comment) suggests that for some reason, sshfs.exe is still picking up the wrong ssh.exe, even though it is receiving an almost empty PATH. (I have no idea how this can be happening. I tried debugging this by replacing ssh.exe by a file that dumps the environment to a file, but that did not work for some reason, and I won't have time to dig much deeper into this.) This suggests that removing any PATH tinkering might not have a negative effect.

Perhaps a better approach would be to copy the environment from Windows and just overwrite PATH. What do you think?

I think just leaving the environment untouched (that is, passing down the original caller's environment using execv) and adding -o ssh_command=bin/ssh.exe would solve both this issue and #95. It has the added benefit that a user who uses sshfs-win.exe ... -d can copy and paste the call to ssh.exe (after removing the awful extra < and >) and debug the ssh call in the exact same environment outside of sshfs-win.exe. This would also reduce the chances of getting additional "work in ssh but not work in sshfs" (#74) in other contexts as well.

[billziss-gh]

@bersbersbers please try the latest beta release where I implemented your suggestions:

• SSHFS-Win now passes the Windows environment mostly unmodified to SSHFS. The only environment variable that is changed is PATH to add a /usr/bin: prefix; this is necessary for correct operation.
• SSHFS-WIn now launches SSHFS with the -o ssh_command=/usr/bin/ssh.exe option.

Please try the latest beta from https://github.com/billziss-gh/sshfs-win/releases and let me know if this works for you. Thanks.

[bersbersbers]

@billziss-gh 2021.1 seems to be working fine, thank you! I was able to remove ssh_command from my connection script and also use sshfs-win.exe directly again. Thanks!

[billziss-gh]

Excellent. Hopefully these changes (esp. the -o ssh_command one) will fix some of the problems that others have as well.

[breisig]

I also installed 2021.1 and it seems Putty Pageant + ssh-agent.exe are working when running sshfs-win.exe directly.

@billziss-gh Would it be possible to bundle the ssh-pageant.exe with the sshfs-win package to make things easier?

[billziss-gh]

@breisig including ssh-pageant is certainly possible, because it is a Cygwin package.

However I am not familiar with the program's operation, because I do not use it. Is it sufficient to just include the program in the bin folder or would it need additional system-wide configuration?

EDIT: On further investigation ssh-pageant appears to be a Cygwin daemon. So I am uncertain whether it could be made to work with SSHFS-Win without issues in some cases, unless we run it as a Windows service.

However this feels beyond the scope of SSHFS-Win, which purports to be a simple and standalone file system solution.

[bersbersbers]

@billziss-gh the steps I outline above are really all it takes (on my system at least). I see two ways:

• To install this permanently, I needed one system-wide environment variable SSH_AUTH_SOCK (or at least the same value set when launching ssh-pageant.exe and when launching sshfs-win.exe) and then need to run ssh-pageant.exe -r -a %SSH_AUTH_SOCK% once per session. (I am not advocating that the SSHFS-Win installer should do that, but maybe the instructions could be added somewhere. Or maybe add an installer option?) This would have the advantage of working system-wide.
• To use this case by case, I just added this before calling sshfs-win.exe:

set SSH_AUTH_SOCK=%TEMP%\ssh-pageant.socket
ssh-pageant.exe -r -a %SSH_AUTH_SOCK%

Maybe sshfs-win.exe could benefit from an optional command line argument to do that. I am not sure how this would combine with the use of net use, but that is not working for me anyways, so my focus is always on sshfs-win.exe.

(Either way, please note that my issue is solved, and further integration of ssh-pageant is something I find valuable, but which is irrelevant for me specifically.)

[breisig]

Is their a way to use this with 'net use'?

[bersbersbers]

@breisig in principle it should, yes. After all, I did not change my calls to sshfs-win.exe, so it should not matter whether I call it or it's called from net use. Of course, for permanent connections to be recreated after reboot, you need to make sure that pageant and ssh-pageant are running before net use tries to reconnect. That seems hard to ensure, particularly if your SSH keys are encrypted and you need to enter a password into pageant. So for me, there is no added benefit to using net use over sshfs-win.exe.

[131]

The latest putty agent listen to a proper named pipe. There is no need for ssh-pageant at all.

[breisig]

@131 oh?

[131]

In the "snapshot" release of puttyagent (0.74+). Putty agent now listen to a named pipe
See https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/

[bersbersbers]

Interesting. I am a bit skeptical this is/will shortly be available in stable build because

• the feature page says it's been fixed in 2019

fixed-in: 98538caa39d20f3efe8de307fa5169e9fb0787d2 2019-01-26

• it's been on the "Recently fixed" list since at least February 2020, see archive.org.

This is certainly valuable for development, but I would not bet on this being able to replace ssh-pageant.exe very soon. Does anyone have additional information on when this feature might actually be included in the release builds?

[breisig]

If this is all true, I would be interested in installing a test pageant build with the instructions for setup the named pipe [assuming something like to set SSH_AUTH_SOCK=\.\pipe\ssh-pageant or whatever the pipe name is ] running the latest test pageant build to see if it works. I know in Windows you can see all the named pipes but running the following in powershell: [System.IO.Directory]::GetFiles("\.\pipe\")

[breisig]

@bersbersbers @131
Actually, I did some testing. I did download and install the latest pageant 64bit snapshot https://www.chiark.greenend.org.uk/~sgtatham/putty/snapshot.html

When running it, I noticed that the new version does initiates a named pipe. It seems to be dynamic as it changes whenever I reboot my computer. [Couldn't find out how to permanent set the named pipe]. Even so, it didn't seem to work for me.

Here's what I did.

• Grabbed the latest Pageant Snapshot: https://www.chiark.greenend.org.uk/~sgtatham/putty/snapshot.html [ https://tartarus.org/~simon/putty-snapshots/w64/pageant.exe ]
• Downloaded and ran it.
• Checked what the named pipe was called. In my case, \.\pipe\pageant.admin.2d23df5f9089407298ed94601b04c261349e072c86465cb4937dcbe333d3708a

 - Open Powershell
   Ran: [System.IO.Directory]::GetFiles("\\.\\pipe\\")
   Found a line that said: \\.\\pipe\\pageant.admin.2d23df5f9089407298ed94601b04c261349e072c86465cb4937dcbe333d3708a

Changed my local User environment variable to match it.
``

• Changed from...
  SSH_AUTH_SOCK: %TEMP%\ssh-pageant.socket
• To
  SSH_AUTH_SOCK: \\.\\pipe\\pageant.admin.2d23df5f9089407298ed94601b04c261349e072c86465cb4937dcbe333d3708a
  or
  SSH_AUTH_SOCK: \\.\pipe\pageant.admin.2d23df5f9089407298ed94601b04c261349e072c86465cb4937dcbe333d3708a
  ``
• Open up a new command prompt window to verify the environment variable SSH_AUTH_SOCK has been set.

set

• It is, then in the same session, I used my regular commands to run sshfs-win but it doesn't seem to recognize my key.

  "C:\Program Files\SSHFS-Win\bin\sshfs-win.exe" svc \sshfs.k\test@test.com\..\..\tmp W: bers -d -o umask=000 -o create_file_umask=133 -o create_dir_umask=002 -o loglevel=debug3 -oreconnect -oStrictHostKeyChecking=no -oPasswordAuthentication=no -oBatchMode=yes -oUserKnownHostsFile=/dev/null -oCompression=yes

[bersbersbers]

@breisig thanks for trying! I don't see anything wrong with what you do, but I have never used named pipes myself. either. What you are assuming, however (pointing out the obvious, maybe), is that

• Cygwin supports accessing named pipes (a quick Googling tells me people have had problems with this, although years ago). Potentially related: Named pipe on cygwin vifm/vifm#189,
• OpenSSH implements that, too (maybe it does not need to, explicitly). Windows 10's OpenSSH ssh.exe seems to support that with some limitation, see https://superuser.com/q/1438513

What you might try:

• test using only ssh.exe (no SSHFS, no SSHFS-Win) to prevent problems such as the one causing this issue originally
  https://github.com/billziss-gh/sshfs-win/blob/bb6c90d35cfb309cf976794a7f12938f1ebee136/sshfs-win.c#L248
• test using a non-Cygwin ssh.exe, in particular, the Windows 10 version mentioned above (https://github.com/PowerShell/openssh-portable)
• try other Cygwin code to connect to the named pipe: https://www.reddit.com/r/sysadmin/comments/1cv9vn/piping_to_windows_named_pipes_from_cygwin/
• connect to the named pipe using another PuTTY instance: https://stackoverflow.com/q/10976284/
• consider escape backslashes in SSH_AUTH_SOCK (no idea if this is relevant, just guessing)

[131]

I’m using npiperelay in wsl to access the windows named pipe in WSL (it is a totally different use case, but it might help you understand what is missing here)

https://stuartleeks.com/posts/wsl-ssh-key-forward-to-windows/

[bersbersbers]

Speaking of WSL, there is also https://github.com/benpye/wsl-ssh-pageant which could be used as another tool to try related use cases. I am not using wsl-ssh-pageant, but it seems well-maintained.

[hboetes]

This is a completely fascinating thread to read, but since I'm not that familiar with windows internals I now have a headache.

Could anyone be so kind to, assuming the latest version of pageant is running with a valid ssh-key, properly installed on the server, explains how to connect to the remote server with SSHFS? A batch file example would be great.

Ideally somebody writes a frontend which

1. generates an ssh key
2. locks it with a passphrase
3. saves it somewhere secure, ~/.ssh/id_rsa
4. tells the user to store the passphrase somewhere safe.
5. uses something like ssh-copy-id to log on to the remote server and install the public key
6. helps users set up network shares
7. sets up SSHFS to connect whilst using the running ssh-agent

But currently it's still a work in progress with lots of loose parts of people who have great intentions but don't see the bigger picture, namely to get one easy to use unified secure network file system.

[bersbersbers]

@hboetes are you aware of https://github.com/evsar3/sshfs-win-manager?

[hboetes]

@bersbersbers

@hboetes are you aware of https://github.com/evsar3/sshfs-win-manager?

Absolutely, it looks nice, but it stores password in cleartext, or uses unencrypted ssh-keys. I already put out a feature request to amend those problems.

I don't want to nag, but do you have an answer to this question?

Could anyone be so kind to, assuming the latest version of pageant is running with a valid ssh-key, properly installed on the server, explains how to connect to the remote server with SSHFS? A batch file example would be great.

[bersbersbers]

I don't want to nag, but do you have an answer to this question?

Could anyone be so kind to, assuming the latest version of pageant is running with a valid ssh-key, properly installed on the server, explains how to connect to the remote server with SSHFS? A batch file example would be great.

If you are looking here, you are looking in the wrong place in my opinion. Points 1-5 in your list in #267 (comment) have nothing to do with SSHFS specifically, but about setting up certificate-based SSH access to your server. If that is possible at all depends a lot on the SSH server configuration (especially thinking about 2FA, for example). I am not sure sshfs-win should can or should cover all these possible cases.

Edit: By the way, this very issue has a couple of examples (e.g., #267 (comment)) on how to connect.

[hboetes]

Edit: By the way, this very issue has a couple of examples (e.g., #267 (comment)) on how to connect.

Much appreciated. Thanks for the heads-up.

[ccy]

Using SSH_AUTH_SOCK and ssh-pageant.exe works for sshfs-win to jump host:

set SSH_AUTH_SOCK=%TEMP%\ssh-pageant.socket
ssh-pageant.exe -r -a %SSH_AUTH_SOCK%

But the Windows OpenSSH ssh-add -L will fail with

error fetching identities: invalid format

And all Windows OpenSSH ssh operations fail to work until we unset

set SSH_AUTH_SOCK=

[ShaunR]

Is this issue suppose to be closed? As of right now doing net use X: \\sshfs\username@host does not authenticate using the SSH key loaded from putty's pagent.