Checklist: Security baseline pre-deploy

Use this checklist before promoting any host to production. Any Critical failure must be resolved before deploy.

How to use this checklist

Run every command on the target host itself, as root. Most of them read files or kernel state that an unprivileged user cannot see, and a check that returns nothing because it was denied looks identical to a check that returns nothing because the host is clean.

Several commands are written so that no output is the pass condition — the world-readable secrets search and the enabled-services grep print only what is wrong. Do not treat silence as a broken command; treat it as the answer. The firewall check is the other shape: it prints one line per base chain, and you are looking for a policy that is not drop. Neither shape asks you to read a full ruleset and decide, which is deliberate — that is the review that passes whatever you expected to find.

openscap-scan is the only item that writes to disk (a report file). Run it somewhere you are content to leave the HTML behind, and attach the report to the deploy ticket rather than recording a bare pass.

Anything you cannot satisfy becomes an exception under exceptions-documented, with an owner and an expiry date. A Critical item is not made acceptable by writing it down — the exception record is how the gap stays visible until it is closed, not how it stops counting.

Verify SSH from the effective configuration, never from the file

grep on sshd_config passes hosts that permit root login

Since OpenSSH 7.3 the main config can pull in other files with Include. Debian and Ubuntu cloud images ship Include /etc/ssh/sshd_config.d/*.conf as the first line of /etc/ssh/sshd_config, and the image drops a 50-cloud-init.conf in that directory. sshd keeps the first value it obtains for a keyword, so a drop-in read at line 1 wins over anything written lower down in the main file.

That inverts the result of a grep. Given a main file whose first line is the Include and whose later lines say PermitRootLogin no:

$ grep PermitRootLogin /etc/ssh/sshd_config
PermitRootLogin no                 <- what the file says

$ sudo sshd -T | grep -i '^permitrootlogin'
permitrootlogin yes                <- what sshd actually does

The checklist would pass a critical item on a host that accepts root logins. grep also cannot see Match blocks, so a config that denies password auth globally and re-enables it for one subnet greps clean.

sshd -T resolves the includes, applies the precedence rules and prints the settings sshd will really use. It is the only trustworthy source for baseline sign-off. Run it as root. It needs to read the host keys, and without them it errors out instead of printing a partial answer you might mistake for a pass.

sshd -T prints the global block only. Overrides inside Match are invisible until you supply the connection attributes to match against, with -C:

$ sudo sshd -T -C user=root,host=$(hostname -f),addr=10.0.0.1 \
    | grep -iE '^(permitrootlogin|passwordauthentication)'

Run that once per source network you actually accept SSH from, plus once for user=root. Any answer other than no on either keyword is a Critical failure, even if the global block is clean.

Sign-off

Operator: _________________ Date: ___________
Reviewer: ________________ Date: ___________

How to use this checklist

Verify SSH from the effective configuration, never from the file

Sign-off

Critical17 items

Warning5 items