They were two sections, and being two is what let the second lock you out of a
machine the first had failed to put a key on. Step 8 could warn-and-skip — no
ssh-keys.zip, or an unrecognised menu choice, since its case had no default arm —
and still mark itself done; step 9 then disabled password authentication and root
login regardless. No key, no password, no root, on a box that may be in a
datacentre.
Nothing here turns off password authentication without first confirming a usable
key is in place, and the refusal says why rather than skipping quietly.
The hardening also did not do anything on a modern Ubuntu, and could not be seen
not to:
It sed'd /etc/ssh/sshd_config. Ubuntu includes /etc/ssh/sshd_config.d/*.conf
from line 12 of that file, and sshd takes the FIRST value it obtains for a
keyword rather than the last. Cloud images ship 50-cloud-init.conf containing
`PasswordAuthentication yes`, read long before the line the sed edited. The run
reported "SSH hardened" and password login stayed on. The settings now go in a
drop-in named 01-machine-setup.conf, which is the only placement that wins
under first-value-wins.
It also sed'd ChallengeResponseAuthentication, renamed to
KbdInteractiveAuthentication in OpenSSH 8.7. On 24.04 the old name is nowhere
in the file, so that substitution matched nothing at all.
State is read with `sshd -T`, which reports what sshd resolves across the main
file and every drop-in — reading the config files tells you what is written, not
what wins.
Keys are counted by asking ssh-keygen to parse authorized_keys rather than by
counting lines: comments, blanks and a half-finished paste all look like lines,
and "there is a file" is not "there is a key that works". A pasted key is
validated before it is stored, and matched on the key body rather than the whole
line, so re-running does not authorise the same key four times over four runs.
sshd -t validates the new config before anything is reloaded, and the drop-in is
restored or removed if it does not parse — a config sshd refuses is a machine
with no ssh after the next restart. Reload rather than restart, so the session
this is running over is not the experiment, and the run says out loud to test a
new connection before closing the current one.
Generating a keypair now says the obvious thing the original did not: the private
key is on the server, and a private key living on the machine it opens is a spare
copy of the lock rather than a second factor.
Verified against this host (1 key, already hardened, correctly does nothing) and
with sshd_effective stubbed to a fresh-cloud-image state — the guard refuses and
harden_sshd is never reached. Also verified key validation, dedup and 0700/0600
permissions.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pastilhasandClaude Opus 5
9591f917f5