Giters

libfuse / sshfs

A network filesystem client to connect to SSH servers

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

sshfs does not prompt to enter yubikey/pin as ssh does. works fine after ssh connection made.

c-george opened this issue · comments

commented

Initial comment
Thanks to all who helped create this FANTASTIC piece of interface software. It has made my life so much simpler!!!

Setup

  • fedora 33/x86-64/gnome/
  • ssh agent retrieving gpg key from yubikey
  • SSHFS version 3.7.1
  • FUSE library version 3.9.3
  • using FUSE kernel interface version 7.31
  • fusermount3 version: 3.9.3

Problem observed

  • When connecting to a remote server (configured for ssh public key authentication only) and having my private key on a yubikey, sshfs does not signal the ssh-agent/gpg-agent to display the "Enter Pin" dialog. Without the pin entry, the key is not available to the ssh agent, and the authentication fails.
  • After a regular ssh connection is made, causing the "Enter Pin" dialog to be displayed (and cached), sshfs works perfectly!

Commands entered on cli
$ sshfs user@10.0.0.1:/remote /local #### no prompt to insert yubikey
read: Connection reset by peer #### sshfs connection failed (understandably)
$ ssh user@10.0.0.1 #### prompts to insert yubikey as expected
Last login: Mon May 3 10:04:25 2021 from 10.0.0.200
$ sshfs user@10.0.0.1:/remote /local #### this succeeds!

Criticality

  • minor
  • (workaround listed above is fully functional and only a minor nuisance)

Request
If this is not an easy fix (i.e. add a flag when calling the ssh library or something like that), I will happily delve into the source code myself (researching ssh/gpg/yubikey API connectivity) and try to experiment and figure out the issue in a month or so. Any advice as to which source files contain the ssh connectivity would be helpful (if they aren't obvious).

commented

Thanks for the report! I'm not sure what's going on there, but here's a few ideas to debug it:

SSHFS is starting an actual SSH process to communicate with the server. I'd enable debugging options and/or use ps to determine the exact commandline being used. Then, run that command by hand and figure out what you need to change to make it work with yubikey.

commented

Thanks for the direction, Nikolaus. It'll be another few weeks until I can look into it properly and I'll update this issue with what I find out then. Cheers.

commented

Additional notes

This problem still exists on fedora 34/gnome

Initial investigation

I used multiple debugging techniques in addition to those suggested by nikratio, and cannot see anything obviously incorrect with what sshfs is passing to ssh.

I did a lot of internet searching, experimenting and testing and found that there is one alternate workaround (originally specified for other yubikey/security card issues) that does seem to resolve this issue with sshfs, even if I couldn't find a satisfactory explanation of why.

REBOOT & LOGIN

$ sudo systemctl restart pcscd

$ sshfs user@10.0.0.1:/remote /local #### this succeeds!

It appears that the pcscd service is somehow partially-initialized (or initialized at the wrong time) leaving it in a state that is somehow incompatible with sshfs. This is strange, given that it seems to be compatible with ssh by itself.

I'm not a big fan of the "just cycle power and it will magically work again" approach to fixing bugs, so I plan on trying to find a proper solution.

Next steps (in order of priority)

  • look into the pcscd power-up sequencing/states externally to sshfs to see if this issue can be resolved at the os-level (the ideal solution since it means no changes to the sshfs project)
  • otherwise see if there is some kind of privilege issue that is occurring (either SElinux or standard linux DAC)
  • otherwise see if there are any additional ssh parameters that will make this problem go away

I'll try to do more investigating during the next week or two when I can find some free time. Hopefully then this issue can be closed with a successful resolution.

commented

Closing comments

I have spent quite a few hours looking into this issue, and I don't believe it should be attributed to sshfs. sshfs is merely a user of the services that have issues.

The following two workarounds are functional (albeit somewhat annoying at times):

a) $ sudo systemctl restart pcscd
or
b) $ ssh (address) # use regular ssh to get the yubikey connection working
$ sshfs (address)

As such, I feel it is best to simply close the issue here.

Once again, thanks to everyone who is developing this software. I still use it every day without problems.