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.

[myllynen]

FWIW, I checked the role I've been using to configure sshd and now I remember that I added an option in the past to reset the configuration to "factory defaults" IOW to the RPM provided defaults. The role supports this only for RHEL 9+ and this is only feasible because the role is only targeting the supported RHEL versions so usually 2-3 RHEL major version and only the latest minor version. So I think there all what's needed is to highlight the need for verifying the contents of the "known" configuration files, one way or the other.

However, as discussed above, here in this generic purpose Linux role targeting multiple distributions similar approach doesn't look maintainable and it is unclear if there exists a straightforward solution to fulfil this RFE. Perhaps at least the documentation could mention something about this, not sure. I'll leave this issue open for your consideration. Thanks.

[Jakuje]

We provide defaults here as well as in the sshd role in https://github.com/willshersystems/ansible-sshd/ for several distros, where somebody cared to provide the defaults or we have a simple way to test it in GH actions. But with drop-in directories and aim to use this as an enforcing mechanism sounds like something I am not sure we want to go into. I am wondering if OpenSCAP would not be a better place to have such a probe that would make sure no unexpected files are in drop-in directory.