Stage the firmware's first-login marker with the authorized key

[abcd-ca]

Fixes the first-contact failure I hit on a fresh Libra Colour (full diagnosis and correction on #49): the firmware's sshd_config forces root through a setup script that runs an interactive passwd until /.login_pass_set exists. Key authentication succeeds, and then the very first non-interactive kobo deploy/doctor after setup --enable-ssh pipes its script into that passwd — the transfer lines are eaten as password input, and the leftovers run as shell commands once the wrapper reaches exec /bin/sh. It presents as the base64 body executing line by line (/bin/sh: f0VMRg…: not found), which I initially misattributed to the shell.

The change

kobo setup --enable-ssh already stages one archive for the firmware to extract as root, carrying this machine's public key. That archive now also carries /.login_pass_set: empty, mode 644, which is byte for byte what the firmware's own touch ${PASS_SET} would have created after a successful interactive password change. Root already carries a password hash in /etc/passwd and access is by key, so the marker gates only the interactive reset, not authentication — the wrapper goes straight to exec /bin/sh on every login, including the first.

• authorize.rs: the marker joins entries() and STAGED_MEMBERS; the module contract ("ships nothing but this machine's public key") is updated to name both things it ships and why.
• setup.rs: the KEY_SCOPE and PLUGIN_AND_KEY_SCOPE reports name the marker and explain it.
• main.rs: the dry-run plan's "nothing extracted as root but…" lines include it.
• Tests: the nothing-but-the-key boundary test now admits exactly the marker; a new test pins its path, emptiness, and mode; the plan-string tests updated.

cargo test -p kobo-cli: 203 passed. Clippy (pedantic) and rustfmt clean.

Scope note

This helps every model whose firmware ships the wrapper (the Clara BW on 4.45.23697 has the same script). On firmwares whose /etc/ssh/initial_ssh_setup.sh doesn't exist the marker is a single inert empty file at /. I considered gating it on the wrapper's presence, but USB setup cannot read the root filesystem to check, and an inert empty file seemed the better trade than a first login that fails interactively — happy to change the approach if you'd rather.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[abhishek-anand]

Before merging, could you confirm the password-authentication posture after the marker is staged? Because this bypasses the firmware’s forced  passwd  step, we should verify that it does not leave root password login enabled with a factory/default credential. Evidence from the effective  sshd  configuration, plus confirmation that key-authenticated  doctor / deploy  succeeds while password authentication is disabled or otherwise safe, would close the remaining concern.

[abcd-ca]

Good thoughts. I dug into it on hardware (Libra Colour, N428, firmware 4.45.23697) and here's what I came up with:

The marker doesn't change the posture, because the forced passwd step was never an authentication gate. It runs as a ForceCommand after SSH authentication has already succeeded. On stock firmware, anyone who can authenticate with the factory credential gets the passwd prompt and then a shell; the wrapper invites them to set the password themselves. So the surface with the marker staged is identical to stock. What the marker removes is the interactive trap that breaks piped, non-interactive sessions (the bug this PR fixes).

That said, the underlying posture is worth spelling out. The effective sshd configuration for root on this firmware (sshd -T -C user=root,...) is:

permitrootlogin yes
passwordauthentication yes
permitemptypasswords yes
forcecommand /etc/ssh/initial_ssh_setup.sh

(The firmware's trailing PermitRootLogin yes / PermitEmptyPasswords yes lines sit after the Match User root line, so they apply inside that block.) There is no /etc/shadow; root's credential is a legacy DES crypt hash in world-readable /etc/passwd. That's the stock reality with or without this PR.

I validated a fix on hardware that closes it properly. Appending a sentinel-guarded block scoped to sshd:

# cobalt-hardening: key-only SSH for root.
Match User root
PasswordAuthentication no

validated with sshd -t, then reloaded. Results on the device:

• effective root context now reports passwordauthentication no
• a fresh key-authenticated login succeeds
• a password-only attempt is refused with Permission denied (publickey) (the method is no longer offered)
• key-authenticated read-only doctor succeeds end to end: result: write ready

Because it's scoped to sshd, serial console login is untouched, and a reverting KoboRoot.tgz over USB remains the recovery path of last resort.

I'd be glad to implement this in the CLI: applied over the first key-authenticated connection (proof by construction that keys work before the password door closes), sshd -t gated, with a timed auto-revert that a fresh key login cancels, idempotent, and removed by setup --undo. Would you want that inside this PR, or as a follow-up so this one stays a one-file fix? Happy either way.

[abhishek-anand]

Thanks for validating this on hardware. The key-only hardening looks good and addresses the concern. Could you please include it in this PR rather than defer it?

[abcd-ca]

Done, it's in this PR now. The last three commits add the hardening to the CLI.

How it works: the wait at the end of kobo setup --enable-ssh already ends with the first key-authenticated connection to the restarted reader, so that connection now carries the hardening. It appends the sentinel-marked key-only block to sshd_config, gated on sshd -t and on sshd -T actually reporting passwordauthentication no (which catches an append to a file the server doesn't read). The saved pre-hardening copy doubles as a deadline: a watchdog on the reader restores it after five minutes unless a second, fresh key login removes it first. That confirming login is made by the same command with connection multiplexing disabled, so its success genuinely proves keys work against the hardened server. If it never arrives, the reader puts itself back and stays reachable. --no-key skips the hardening (no key, no proof to stand on), setup --undo removes the block over Wi-Fi since USB can't reach the root filesystem, and both dry runs disclose all of it.

Validated on the same hardware as before (Libra Colour N428, 4.45.23697), using the byte-exact scripts the CLI sends: apply/commit works and password authentication is no longer offered afterwards; deliberately withholding the confirming login had the watchdog restore the config byte-identical to the original after five minutes, with keys working throughout; removal takes out exactly the sentinel range and sshd -T reports yes again.

Testing on hardware also caught two edge cases around a block applied by hand before this existed (like the one from my earlier comment): detection now matches the # cobalt-hardening: marker prefix rather than the exact line, so a rerun won't append a second block, and removal refuses a block that has no end marker instead of running a sed range to the end of the file. The ordering that carries the safety argument is pinned by tests, and each script is syntax-checked through sh -n.

[abhishek-anand]

Thanks for adding the hardening. Before merging, could you make it fail closed when  sshd -T  returns no effective  PasswordAuthentication  value, and build/validate the complete config in a temporary file before replacing the live one? An interrupted append can currently leave a partial block that a retry treats as already applied. Please also avoid re-enabling password login during  setup --undo  before SSH is actually disabled.