Please add assertion for ubtu22cis_sshd formatting

[dderemiah]

Feature Request or Enhancement

• Feature [assert that ubtu22cis_sshd:{ciphers,macs,kex_algorithms} are the new format ]
• Enhancement [prevent breaking sshd_config and locking admins out]

Summary of Request Please add an assertion for the new format of ubtu22cis_sshd:{ciphers,macs,kex_algorithms} . The reason for this is this is a common var that is overridden and when the old var format is applied to new control implementation in community_work branch results in a broken sshd_config

Describe Alternatives You've Considered A simpler alternative would be to implement versioning of the defaults main.yml and increment when changing it in ways that are not compatible with previous implementations.

Suggested Code Unfortunately, I am not at the skill level yet that I could write a sample.

[uk-bolly]

hi @dderemiah

The changes are just to the format of the variable and the way it can be reused in other locations, there should have been no impact to the previous settings. While i try to replicate this problem, just to confirm the understanding if you could provide a copy of your current settings, so we can see if we understand the exact issue.

many thanks

uk-bolly

[uk-bolly]

hi @dderemiah

Just to follow up i have run with the current devel (the changes as expected were made) and the new community_work_fix branch and it doesn't change the the config and sshd is able to be restarted without an issue. So if you do have a copy of your settings and the latest community branch changes still break please let us know.

TASK [Linux/REMEDIATE/UBUNTU22-CIS : 5.2.13 | PATCH | Ensure only strong Ciphers are used] *************************************
ok: [ubuntu22_04]

TASK [Linux/REMEDIATE/UBUNTU22-CIS : 5.2.14 | PATCH | Ensure only strong MAC algorithms are used] ******************************
ok: [ubuntu22_04]

TASK [Linux/REMEDIATE/UBUNTU22-CIS : 5.2.15 | PATCH | Ensure only strong Key Exchange algorithms are used] *********************
ok: [ubuntu22_04]

many thanks

uk-bolly

[dderemiah]

If I am changing the defaults using a vars_file with the role and I have the the old format of : ubtu22cis_sshd: log_level: "INFO" max_auth_tries: 4 ciphers: "chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr" macs: "hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256" kex_algorithms: "curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256" client_alive_interval: 300 client_alive_count_max: 3 login_grace_time: 60 max_sessions: 8 allow_users: "" allow_groups: "" deny_users: "ubuntu" deny_groups: "uucp"

And I update my role with the community fixes and don't notice that the format of ciphers,macs, and kex_algorithms has changed, I will end up with a invalid sshd_config . Normally this would not be a huge issue because I could correct the vars file and rerun but don't you agree since this is a common condition and it breaks Ansible indirectly by disabling ssh, that it warrants an assertion?

[uk-bolly]

hi @dderemiah

Thank you again for the feedback on this, while the changelog is updated to state the changes, this could be a good idea to ensure that the new format is followed. I will work to add a assertion that the ssh formats are in the correct layout.

Many thanks

uk-bolly

[uk-bolly]

hi @dderemiah

I believe this should now be resolved, i have added a validate to each section to test the configuration is valid before allowing the commit, rather than using another assert. This has been merged and added to devel, please let me know if this fixes the issues for you?

many thanks

uk-bolly

[dderemiah]

Confirmed this fixes the issue. Thanks Bolly!

[uk-bolly]

hi @dderemiah

I believe that this issue has been addressed and the fix merged? I will close this issue, please feel free to reopen or raise a new one if this particular problem still exists.

Many thanks

uk-bolly