Allow custom SSH options #111

New Issue

ungleich-gitea · 2021-11-20T13:24:05Z

ungleich-gitea commented

2021-11-20 13:24:05 +00:00

Created by: matthijskooijman

To customize the way cdist connects to my target hosts, it would be nice if there was an easier way to pass options to the ssh and scp commands. In particular, I'm looking for -o ProxyJump=some_server to allow using a jump host for connections.

Currently, this can be supported using the --remote-exec and --remote-copy options (or their associated config file equivalents). However, this has a number of downsides:

This requires duplicating all default options as well: 1f2b7c84c2/cdist/init.py#L46-L47
This requires separately specifying the ssh and scp commands.
This breaks support for using a control connection, which only works when cdists constructs the command (and it seems that without a control connection, cdist becomes unusably slow for me...)

To circumvent these, a new commandline (and config) option could be useful. E.g. --ssh-option ProxyJump=some_server, or --ssh-argument -oProxyJump=some_server could help here, if cdist would keep the existing logic for generating the commands, but just adds some extra options. Just adding -o options to SSH is probably enough (and -o is certainly supported by both ssh and scp).

How does that sound?

*Created by: matthijskooijman* To customize the way cdist connects to my target hosts, it would be nice if there was an easier way to pass options to the `ssh` and `scp` commands. In particular, I'm looking for `-o ProxyJump=some_server` to allow using a jump host for connections. Currently, this can be supported using the `--remote-exec` and `--remote-copy` options (or their associated config file equivalents). However, this has a number of downsides: - This requires duplicating all default options as well: https://github.com/ungleich/cdist/blob/1f2b7c84c2c56b69267321174971794da2d1b986/cdist/__init__.py#L46-L47 - This requires separately specifying the ssh and scp commands. - This breaks support for using a control connection, which only works when cdists constructs the command (and it seems that without a control connection, cdist becomes unusably slow for me...) To circumvent these, a new commandline (and config) option could be useful. E.g. `--ssh-option ProxyJump=some_server`, or `--ssh-argument -oProxyJump=some_server` could help here, if cdist would keep the existing logic for generating the commands, but just adds some extra options. Just adding `-o` options to SSH is *probably* enough (and `-o` is certainly supported by both ssh and scp). How does that sound?

ungleich-gitea added the

Stale

label 2021-11-20 13:24:05 +00:00

ungleich-gitea closed this issue

2021-11-20 13:24:05 +00:00

ungleich-gitea commented

2021-11-20 15:40:13 +00:00

closed

ungleich-gitea commented

2021-11-20 15:40:14 +00:00

Created by: telmich

This is a very interesting discussion. My two points for the moment (more to come):

cdist should stay agnostic of transport
cdist should support remembering transport specific parameters

The former is already there, the latter is well reasoned by the transport being a configuration parameter.

It could be solved in a variety of ways - a quick one I can think of is extending the inventory functionality to register host specific transport settings - however this approach might not be general enough and we might want to re-evaluate thoughts @asteven already had for generic protocol combination.

This could also open the door for something like:

host a: use ssh as user x + sudo
by default: use tcp, port 2342

@matthijskooijman are you already on https://chat.ungleich.ch/ungleich/channels/cdist ? when you are back, we would have a discussion over there on how to progress

*Created by: telmich* This is a very interesting discussion. My two points for the moment (more to come): - cdist should stay agnostic of transport - cdist should support remembering transport specific parameters The former is already there, the latter is well reasoned by the transport being a configuration parameter. It could be solved in a variety of ways - a quick one I can think of is extending the inventory functionality to register host specific transport settings - however this approach might not be general enough and we might want to re-evaluate thoughts @asteven already had for generic protocol combination. This could also open the door for something like: - host a: use ssh as user x + sudo - by default: use tcp, port 2342 @matthijskooijman are you already on https://chat.ungleich.ch/ungleich/channels/cdist ? when you are back, we would have a discussion over there on how to progress

ungleich-gitea commented

2021-11-20 15:40:16 +00:00

Created by: matthijskooijman

Cdist is currently not really tied to ssh in any way.

Well, the default commands that are generated call SSH, with SSH-specific options, so it is tied to SSH somewhat. That options I propose tie in to that SSH-default part, so it might actually be sensible to call them --ssh-whatever. I don't care overly much, though.

Regarding using a ssh master control socket you can of course do this yourself in a remote-{exec,copy} script or in ~/.ssh/config as well.

But, ssh mux options can also be specified with --remote-exec/copy, or not!?

You, could, except:

You would have to hard-code the control path, rather than have cdist generate it, which prevents running multiple cdists in parallel, I think.
You would have to manually clean up the session, rather than tmux killing it a the end

Regarding your request about having all config in the repo what I have done sometimes is to have a customer specific shell script wrapper in the repo, e.g. ./bin/my-cdist that exports env vars, or pre-processes parameters and then exec's cdist as needed.

That could work, except I do not know what env vars to set, or how to preprocess the variables. AFAIU SSH does not support passing -o options through the environment, or changing the config file, and the only parameters I can preprocess are --remote-exec and --remote-copy, which runs into the above problem (though, thinking of it, I could generate a control path in the wrapper script and clean up the session afterwards. Not super-pretty, but I could consider that. Still needs me to hardcode all default options in the script, making it break if additional options are needed in the future, but I guess that's a compatibility problem that cdist might need to solve anyway).

I'm not necessarily against all this. I'm just questioning if your use case is generic enough to be implemented upstream, iow: can this be made usefull for others?

Definitely a good process, helps me to think better about what I really need as well :-)

Note that I'll be away on vacation for the next three weeks, so I won't be able to respond until then.

*Created by: matthijskooijman* > Cdist is currently not really tied to ssh in any way. Well, the default commands that are generated call SSH, with SSH-specific options, so it is tied to SSH *somewhat*. That options I propose tie in to that SSH-default part, so it might actually be sensible to call them `--ssh-whatever`. I don't care overly much, though. > Regarding using a ssh master control socket you can of course do this yourself in a remote-{exec,copy} script or in ~/.ssh/config as well. > But, ssh mux options can also be specified with --remote-exec/copy, or not!? You, could, except: - You would have to hard-code the control path, rather than [have cdist generate it](https://github.com/ungleich/cdist/blob/eeb059015029208ec55131caf2e5f17c3bd0b738/cdist/config.py#L294-L298), which prevents running multiple cdists in parallel, I think. - You would have to manually clean up the session, rather than [tmux killing it a the end](https://github.com/ungleich/cdist/blob/eeb059015029208ec55131caf2e5f17c3bd0b738/cdist/config.py#L134-L138) > Regarding your request about having all config in the repo what I have done sometimes is to have a customer specific shell script wrapper in the repo, e.g. ./bin/my-cdist that exports env vars, or pre-processes parameters and then exec's cdist as needed. That could work, except I do not know what env vars to set, or how to preprocess the variables. AFAIU SSH does not support passing `-o` options through the environment, or changing the config file, and the only parameters I can preprocess are `--remote-exec` and `--remote-copy`, which runs into the above problem (though, thinking of it, I could generate a control path in the wrapper script and clean up the session afterwards. Not super-pretty, but I could consider that. Still needs me to hardcode all default options in the script, making it break if additional options are needed in the future, but I guess that's a compatibility problem that cdist might need to solve anyway). > I'm not necessarily against all this. I'm just questioning if your use case is generic enough to be implemented upstream, iow: can this be made usefull for others? Definitely a good process, helps me to think better about what I really need as well :-) Note that I'll be away on vacation for the next three weeks, so I won't be able to respond until then.

ungleich-gitea commented

2021-11-20 15:40:17 +00:00

Created by: darko-poljak

But, ssh mux options can also be specified with --remote-exec/copy, or not!?

*Created by: darko-poljak* But, ssh mux options can also be specified with --remote-exec/copy, or not!?

ungleich-gitea commented

2021-11-20 15:40:18 +00:00

Created by: darko-poljak

@asteven @matthijskooijman @telmich Generally, I don't like very much when a tool bloats with options. And here, in my opinion, even with --remote-argument, this new option would still be present only for default ssh remote copy/exec, because for any custom copy/exec it is supported with --remote-exec/copy.
As I understand, the only problem when specifying custom --remote-exec/copy and you still want to use default ssh, is that multiplexed connections are not well supported? Perhaps we should reconsider how to support and/or refactor it?

*Created by: darko-poljak* @asteven @matthijskooijman @telmich Generally, I don't like very much when a tool bloats with options. And here, in my opinion, even with --remote-argument, this new option would still be present only for default ssh remote copy/exec, because for any custom copy/exec it is supported with --remote-exec/copy. As I understand, the only problem when specifying custom --remote-exec/copy and you still want to use default ssh, is that multiplexed connections are not well supported? Perhaps we should reconsider how to support and/or refactor it?

ungleich-gitea commented

2021-11-20 15:40:20 +00:00

Created by: asteven

Cdist is currently not really tied to ssh in any way. I'm not sure I like adding any ssh specific options. But I'm also not against it as long as it stays out of the way and does not give the idea that ssh is the only option for remote-{exec,copy}. If we'd consider this I'd vote for --remote-option --remote-argument or the like instead of --ssh-*. Then again, can this not be done with the existing --remote-{exec,copy} already?

Regarding using a ssh master control socket you can of course do this yourself in a remote-{exec,copy} script or in ~/.ssh/config as well.

Regarding your request about having all config in the repo what I have done sometimes is to have a customer specific shell script wrapper in the repo, e.g. ./bin/my-cdist that exports env vars, or pre-processes parameters and then exec's cdist as needed.

I'm not necessarily against all this. I'm just questioning if your use case is generic enough to be implemented upstream, iow: can this be made usefull for others?

@darko-poljak, @telmich: what say you?

*Created by: asteven* Cdist is currently not really tied to ssh in any way. I'm not sure I like adding any ssh specific options. But I'm also not against it as long as it stays out of the way and does not give the idea that ssh is the only option for remote-{exec,copy}. If we'd consider this I'd vote for --remote-option --remote-argument or the like instead of --ssh-*. Then again, can this not be done with the existing --remote-{exec,copy} already? Regarding using a ssh master control socket you can of course do this yourself in a remote-{exec,copy} script or in ~/.ssh/config as well. Regarding your request about having all config in the repo what I have done sometimes is to have a customer specific shell script wrapper in the repo, e.g. ./bin/my-cdist that exports env vars, or pre-processes parameters and then exec's cdist as needed. I'm not necessarily against all this. I'm just questioning if your use case is generic enough to be implemented upstream, iow: can this be made usefull for others? @darko-poljak, @telmich: what say you?

ungleich-gitea commented

2021-11-20 15:40:21 +00:00

Created by: matthijskooijman

I fiddled around with ~/.ssh/config, which can be made to work, but requires me to keep a list of hostnames in my homedir, while I really want to keep everything on our cdist-fork (so things can be more easily shared between different people in our project, and project-specific config does not leak out of the project repo).

Also, I'd like to be able to easily enable and disable these options (e.g. I'll need the proxyjump for hosts that are already deployed to the production network, but when initially configuring them, I'll have direct network access). Being able to (not) pass a single --ssh-option, or even nicer, a -g option to point cdist to the right config file would help here, none of which works with ~/.ssh/config.

*Created by: matthijskooijman* I fiddled around with ~/.ssh/config, which can be made to work, but requires me to keep a list of hostnames in my homedir, while I really want to keep everything on our cdist-fork (so things can be more easily shared between different people in our project, and project-specific config does not leak out of the project repo). Also, I'd like to be able to easily enable and disable these options (e.g. I'll need the proxyjump for hosts that are already deployed to the production network, but when initially configuring them, I'll have direct network access). Being able to (not) pass a single `--ssh-option`, or even nicer, a `-g` option to point cdist to the right config file would help here, none of which works with ~/.ssh/config.

ungleich-gitea commented

2021-11-20 15:40:22 +00:00

Created by: asteven

I use ~/.ssh/config for this. Could this also work for you?
We should be very hesitant to add any features/config to cdist that can already be done with existing tools/configs.

*Created by: asteven* I use ~/.ssh/config for this. Could this also work for you? We should be very hesitant to add any features/config to cdist that can already be done with existing tools/configs.

Sign in to join this conversation.