Provide granular noop for ssh configuration #789
Conversation
seven-beep
force-pushed
the
master
branch
2 times, most recently
from
a5d7464 to
c55f95b
Compare
|
The pgp signing should be ok now. |
seven-beep
force-pushed
the
master
branch
2 times, most recently
from
776189a to
ea9cdd7
Compare
|
Well I guess it is more valid to use new variables to implement this behavior. |
We would like to have more fine grained options on applying or not specific configurations. This commit let the user choose to noop some configuration with a few new boolean variables. Motivation for theses options are we may configure ourselves some (ssh host key regeneration in a templating system) or we are not ready for others (ssh_kex will break dist-upgrades, letting the operator without ssh). Signed-off-by: seven beep <ebn@entreparentheses.xyz>
|
I corrected a few mispellings that was caught by codespell. |
| @@ -73,14 +73,14 @@ LogLevel {{ sshd_log_level }} | |||
| # -- see: (http://net-ssh.github.com/net-ssh/classes/Net/SSH/Transport/CipherFactory.html) | |||
| # | |||
| {# This outputs 'Ciphers <list-of-ciphers>' if ssh_ciphers is defined or '#Ciphers' if ssh_ciphers is undefined -#} | |||
| {{ 'Ciphers ' ~ ssh_ciphers|join(',') if ssh_ciphers else 'Ciphers'|comment }} | |||
| {{ 'Ciphers ' ~ ssh_ciphers|join(',') if ssh_ciphers and ssh_ciphers_config else 'Ciphers'|comment }} | |||
There was a problem hiding this comment.
This and the changes for MACs and Kex shouldn't be needed since ssh_ciphers can only be set in two ways:
- define it as a variable, then
ansible.builtin.include_tasks: crypto_ciphers.ymlwon't be run. - by the tasks in
ansible.builtin.include_tasks: crypto_ciphers.yml
Or is there something I am missing where we want to define Ciphers but not actually configure them?
There was a problem hiding this comment.
Actually on main we have :
- If I don't define them as a variable, the tasks crypto_ciphers.yml will define them for me and the template will use the defaults and hardcode them in the configuration file.
- If I define them as a non true variable, the same apply as I wasn't defining them.
- If I define them as a variable, the template will use this variable and hardcode them in the configuration file.
So what about if I doesn't want to define Ciphers and does not want to configure them ?
| @@ -34,7 +34,7 @@ ListenAddress {{ address }} | |||
| {% endfor %} | |||
|
|
|||
| # HostKeys are listed here. | |||
| {% for key in ssh_host_key_files %} | |||
| {% for key in ssh_host_key_files if ssh_host_key_config%} | |||
There was a problem hiding this comment.
Can we do something like {{ 'Ciphers ' ~ ssh_ciphers|join(',') if ssh_ciphers and ssh_ciphers_config else 'Ciphers'|comment }} here, too?
|
@seven-beep I understand what you are trying to implement here and I see value in it, especially for system updates. What I don't want is introduce even more variables as switches for these values. @rndmh3ro what do you think about removing the cipher variables ( |
Good idea! @seven-beep what do you think? |
schurzi
changed the title
We would like to have more fine grained options on applying or not specific configurations. This commit let the user choose to disable configurations for `ssh_host_key_config`, `ssh_ciphers_config`, `ssh_host_key_config`, `ssh_macs_config` by setting them to False. Motivation for theses options are we may configure ourselves some (ssh host key regeneration in a templating system) or we are not ready for others (ssh_kex will break dist-upgrades, letting the operator without ssh). Signed-off-by: seven beep <ebn@entreparentheses.xyz>
|
I agree that less variables is desirable, and it was my original intent to not add any new variables to get this feature. However I think I got caught by the meta/argument-specs.yml of the role because we might lose proper typing for the variables by allowing them to be a list or a boolean. I implemented your recommendation in the last iteration, if this fails because of the meta/argument-specs.yml, I might need advice on this particular point. |
|
LGTM! Will test it some more. |
Hello,
We would like to have more fine grained options on applying or not specific configurations.
This commit let the user choose to noop some configuration by setting their value to false.
Another option would have been to create more variables but I was reticent to do so.
Motivation for theses options are we may configure ourselves some (ssh host key regeneration in a templating system) or we are not ready for others (ssh_kex will break dist-upgrades, letting the operator without ssh).