Worked example: a synthetic Linux baseline verification sheet

This is invented, not a record of a real server

Every value below is made up to show the shape of the evidence. The host name, addresses and results do not describe any real server, run or customer. The sheet is what a buyer should expect to be handed at the end of a baseline job so they can check it themselves rather than take a statement on trust.

• Server: one synthetic Ubuntu server called demo-web-1.
• Administrators: two named people, each with their own key.
• Ports that must be open: 22, 80, 443.

The sheet

Each row has what was checked, the command or method, the expected result and what counts as a failure. The right-hand column is empty on purpose: the buyer or their administrator fills it in on their own server.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

check                         method                           expected                    pass/fail
SSH password login off        sshd -T | grep passwordauth     passwordauthentication no   ________
Keyboard-interactive off      sshd -T | grep kbdinteractive   kbdinteractiveauthentication no  ________
Root login                    sshd -T | grep permitroot       prohibit-password or no     ________
Password attempt refused      ssh -o PreferredAuthentications=password ...   Permission denied   ________
Admin A key login             ssh -i key-A ...                login succeeds              ________
Admin B key login             ssh -i key-B ...                login succeeds              ________
Unlisted key refused          ssh -i other-key ...            Permission denied           ________
Open ports (IPv4)             connection test from outside    22, 80, 443 only            ________
Open ports (IPv6)             connection test from outside    22, 80, 443 only            ________
Container-published ports     docker ps + outside test        none, or listed             ________
Update dry run                unattended-upgrade -v --dry-run security origin allowed, no error  ________
Update timers                 systemctl list-timers           apt timers enabled          ________
Reboot setting                grep Automatic-Reboot ...       the value you chose         ________

How to read a failure

A password attempt that is not refused means an included file or a Match block overrides the setting, so read the effective output, not the file. An unlisted key that logs in means an old key is still authorised somewhere. An unexpected open port is the most important row: find what is listening, and for container-published ports remember the host firewall does not govern them. A dry run that errors usually means a repository or a held package; the baseline is not finished until it passes. Any failing row is a finding, not something to hide.

• Record the exact output, not just pass or fail.
• Re-run the whole sheet after any later change.
• Keep the revert steps with the sheet.

What the sheet does not prove

Passing every row shows that three specific controls are in place on one server today. It is not a penetration test, a vulnerability scan or a certification, and it says nothing about the applications on the server. Treat it as a baseline to maintain, which is what a monthly review is for.