Open brooksvb opened 2 years ago
Which name should it use for the mount? The hostname?
Which directory should it mount?
Us writing an ~/.ssh/config
parser is probably complicated and if available should only be one way of doing things. I have 56 definitions in my ~/.ssh/config
file, but I definitely don't want to connect to any of them using SSHFS. For me, this would be an anti-feature.
I should have been more specific.
No need to write a parser at all; just let me define an existing sshconf host that gets passed to the sshfs command. The name for the mount is already defined by the --id
option. Just use that.
Example of an sshfs command I use, which uses an ssh profile: sshfs boxy:/usr/home/foo /mnt/foo
, where boxy
is the configured host in my sshconf. This command works already without sftpman.
The equivalent for sftpman could be something like sftpman create --id=foo --sshconf_host=boxy --mount_point=/usr/home/foo
, which should then run sshfs boxy:/usr/home/foo /mnt/sshfs/foo
.
Currently, if I try to run sftpman setup --id=foo --host=boxy --mount_point=/usr/home/foo
, it causes the following errors:
Invalid data found:
- ssh_key: Invalid ssh key path.
- user: Usernames can only contain letters, at signs and digits.
So if perhaps the ssh_key and user could be made optional, things would work as expected for me. Or define a separate option like sshconf_host that allows them to be empty.
I have 56 definitions in my ~/.ssh/config file, but I definitely don't want to connect to any of them using SSHFS
Well... I do. Any host that I frequently SSH into is going to have an sshconf entry with all the options I need for that host. Why would it be unexpected that I would want to mount a directory from one of my ssh targets? Is that literally not what sshfs is for?
I suppose we could make the username and SSH key configuration options optional. When sftpman
generates the sshfs
command it will just leave those out and sshfs
will read the configuration for the provided host by ~/.ssh/config
. It makes sense to have this.
Or perhaps it would make sense for it to be another --auth_method
?
--auth_method={method}
Specifies the authentication method.
Can be `password`, `publickey`, `hostbased`, `keyboard-interactive` or `gssapi-with-mic`.
That way the error messages still communicates what options are needed in the default case. It seems like running the sshfs thishostismissing:/usr/home/foo /mnt/foo
just outputs read: Connection reset by peer
, so it might be hard to distinguish if a user who just provided --host
actually intended to and is using a host that has a configuration but the remote timed out, or if they intended to but it's a typo, or if they don't understand they need the other options.
I don't understand what the "hostbased" auth method is for. That almost sounds like it's supposed to be the behavior I want here, but it's something else.
Would a change like this require an update to the GTK gui as well?
From what I remember, the GTK UI relies on the CLI library for validation, etc., so maybe we don't need to change the GTK UI.
But if we have to change it a bit, it's no problem to do it later.
If I have my host and ssh options already defined in sshconf, I should be able to just use that config and not have to redefine everything.