Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use configured sshconf host #15

Open
brooksvb opened this issue Feb 13, 2022 · 5 comments
Open

Use configured sshconf host #15

brooksvb opened this issue Feb 13, 2022 · 5 comments

Comments

@brooksvb
Copy link

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.

@spantaleev
Copy link
Owner

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.

@brooksvb
Copy link
Author

brooksvb commented Feb 14, 2022

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?

@brooksvb brooksvb changed the title Use sshconf Use configured sshconf host Feb 14, 2022
@spantaleev
Copy link
Owner

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.

@brooksvb
Copy link
Author

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?

@spantaleev
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants