RFE: Allow removing unrecognized ssh configuration files

[myllynen]

In case there's a configuration file present in the ssh_config.d directory then the role configured options do not necessarily get used if the unexpected configuration file has higher priority.

It would nice to be able to have the role to remove all unrecognised configuration files from ssh_config.d. On RHEL, for instance, there might be few non-role configuration files created by security hardening tools such as oscap(8) which would be ok to be left in place whereas something like 0-test.conf or 0-rogue.conf should be removed.

Thanks.

[richm]

@myllynen how can the role know which files are ok to remove? That is, what does "unrecognised" mean in this context, and how can the role know which files are "unrecognised"? I know that I looked at this for the logging role - to remove "unrecognized" files in /etc/rsyslog.d - but it proved to be very difficult because some packages (e.g. cloud-init) drop config files there, and it is difficult to determine if they can be removed safely or not.

[myllynen]

I solved this question by defaulting to "well-known" RHEL/OpenSCAP provided files but allow the list to be configurable - it gives flexibility for role users but still ensure no unexpected files, intentional or not, would cause issues. And by default this is not in use so nothing will get removed unless explicitly so requested.

See https://github.com/myllynen/rhel-ansible-roles/tree/master/roles/sshd_configuration for reference. Thanks.

[richm]

I solved this question by defaulting to "well-known" RHEL/OpenSCAP provided files but allow the list to be configurable - it gives flexibility for role users but still ensure no unexpected files, intentional or not, would cause issues. And by default this is not in use so nothing will get removed unless explicitly so requested.

See https://github.com/myllynen/rhel-ansible-roles/tree/master/roles/sshd_configuration for reference. Thanks.

I prefer not to deal with such hardcoded lists - they are technical debt, have to be constantly maintained, may be different for different operating systems and versions - but maybe this is the easiest way to handle this situation.

@Jakuje what do you think?

[Jakuje]

I agree that keeping hardcoded lists like this will just make them outdated and cause unexpected behavior for users. You already found the permitrootlogin file that is dropped there by anaconda during installation. There is also an IPA dropping in a configuration file in there, that should not be touched either, but there might be others that might be crucial. But removing everything else really does not protect from anything as the rogue file could be named as one of your whitelisted files.

I think the only way to be sure nothing else is included is to specify the whole main sshd_config without include (which obviously has a drawback of not being as modular as we OS maintainers want).

[myllynen]

That is a very good point. In my role the tasks always rewrite the separate config file in sshd_config.d but the recognized files are assumed to be intact, perhaps by periodic OpenSCAP scans and runs. But I think this is something that should be brought up clearly in the documentation, perhaps even change the mechanism so that the recognized files must be copied in place by the role. Which then adds administrative burden so indeed using only the main config file might be more feasible in that case.

As you say, enabling "exclusive" configuration would not enable includes and it would always rewrite the main config file, in that case we should always be alerted if the configuration is updated behind the scenes.

But since detecting rogue config files is not limited to sshd only perhaps those requiring it should create a dedicated role for the purpose, use an existing security tool, or find some other service-agnostic solution instead of adding complexity to several roles.