Hardened SSH to 24 asserted directives with three‑stage validation — the candidate file, the assembled config, then the daemon's own read‑back — after the read‑back caught the running server silently overriding two of the twenty‑four.

Situation. SSH is the only interactive way into the company’s host, and its configuration is written by an automation role that had been running clean for months. An access report in September 2026 read the daemon’s own resolved settings and found two of them disagreeing with what the role had been writing on every single converge.

Task. The hardening had to become something the daemon confirms rather than something the repository asserts, because the gap between the two had already been open for months without anyone noticing.

Action. The cause was configuration ordering. The operating system ships its own defaults uncommented, above where a drop‑in file lands, and for the two settings in question the first occurrence wins. The fix was a filename prefix that sorts ahead of the vendor’s, which is a one‑character class of change and exactly the sort that stays broken because nobody thinks to look. What was built around it matters more: three stages of validation on every converge. The candidate file is syntax‑checked before it is installed, so an invalid config never reaches the host. The assembled configuration is checked after installation. Then the daemon’s own resolved output is read back and 24 directives are asserted against it, so a setting that is written but overridden fails the run. Two directives were deliberately left out, both because the daemon no longer implements them and writing them would only look thorough.

Result. The SSH posture is now the daemon’s answer rather than the repository’s claim, and the difference is not theoretical — it was already two settings wide when the check was written. A converge that cannot see whether a control took effect has not verified it, and grepping for a directive only proves it was written.