Offer the sshd fix the row says is missing, and count the kernel fixes it has

[edimarlnx]

Two rows promised a change the tool then would not make. Both were found on
camera and reproduced on a real machine.

The ssh probe only viewed

probeSSH set Fix.Tool = "tui-ssh (planned)" as its first statement and
never cleared it, so the detail screen credited a tool that does not exist yet
for the six keywords tui-secure sets itself. The fix column showed the same
whenever the actions came out empty, and they came out empty more often than
they should have: the row was graded by one rule and offered by another.
MaxAuthTries is the clearest case — the probe warned above 6 while
SSHDKeys wanted 4, so a stock sshd at 6, the value OpenSSH ships, was
painted as a finding with nothing behind a.

Grading now lives in the SSHDKeys table next to Weak, so a keyword cannot
be flagged by one half and refused by the other, and TestSSHDGradeMatchesWeak
drives both over a corpus of values to hold them to it. A keyword sshd did not
report is unknown rather than ok — nobody read it — and the hint says
sshd -T needs root instead of leaving an empty fix column.

On a Fedora 41 container with a stock sshd:

0.2.1  ssh warn  fix=tui-ssh (planned)
       actions: PermitRootLogin, PasswordAuthentication, X11Forwarding

this   ssh warn  fix=a to fix here
       actions: PermitRootLogin, PasswordAuthentication, MaxAuthTries,
                X11Forwarding

Four weak rows, four fixes, and the tool names itself.

The kernel row counted what it would not fix

It said "4 hardening key(s) below the recommended value" over a picker holding
three, because net.ipv4.ip_forward is graded and deliberately never offered.
Both backends now grade through one GradeHardening, whose summary counts the
fixes it returns and puts the advisory key in a clause of its own:

3 hardening key(s) below the recommended value, and 1 worth a look this
tool leaves alone

A key nobody could read counts as neither.

Validated

• make lint, go test ./..., test/smoke.sh (26 passed).
• --demo parity: the sample sshd now offers Set PasswordAuthentication to no and Set MaxAuthTries to 4, and applying both turns the row green. The
  demo's sshd state is an overlay rather than one hard-coded field, so every
  keyword moves in --demo as it would on a machine.
• A throwaway Fedora 41 systemd container with a real sshd: MaxAuthTries
  6 → 4 through the staged file, sshd -t -f, the install and the reload,
  with the probe flipping afterwards. TestRealAppliesTheSSHDChange and
  TestRealNamesTheDropInThatShadowsIt drive it; both skip unless
  TUI_SECURE_ROOT_LAB=1 and the process is root, so CI never runs them.
• The same run showed why the shadow warning earns its place: Fedora's
  50-redhat.conf sets X11Forwarding and sorts before 50-tui-secure.conf,
  so the file this tool writes is read and ignored. The dialog already said so;
  the README now says it too.

The demo router VM was not reachable while this was written (the lab
hypervisor is down), which is why the container stands in for it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MCypLQF5AD8JD831Ea9S9q