Merge pull request #217

Merged via box work CLI
Investigate StrictModes dial-in denial on container 646
2026-10-09 23:11:14 +00:00 · 2026-10-09 22:54:50 +00:00
1 changed files with 57 additions and 0 deletions
@@ -0,0 +1,57 @@
 # Ticket #215 verification — SSH StrictModes on /home/hatch
 Date: 2026-10-09 ~23:00 UTC
 Operator: operator-646 (muse-646-patha)
 Branch: `dev/646/215-strictmodes-fix`
 ## Ticket premise
 #215 claims OpenSSH StrictModes rejects public-key auth on port 2226
 "for user hatch" because `/home/hatch` is `drwxrws---` (group-writable
 setgid), and asks whether `chmod g-w /home/hatch` or `StrictModes no`
 permits dial-in.
 ## Investigation
 1. **No `hatch` user exists.** `/etc/passwd` has only `root` plus system
   `nologin` users. The only viable dial-in identity is `root`
   (`PermitRootLogin without-password`, i.e. pubkey-only).
 2. **Effective sshd config** (`sshd -T`): `strictmodes yes`,
   `authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2`
   (relative to the login user's passwd home — for root, `/root`).
 3. **Root's auth path is StrictModes-clean** and does not include
   `/home/hatch`:
   - `/` → `755 root:root`
   - `/root` → `700 root:root`
   - `/root/.ssh` → `700 root:root`
   - `/root/.ssh/authorized_keys` → `600 root:root` (holds 646's
     `id_ed25519.pub` + `id_frontdoor.pub`, installed by
     `recover-after-rebuild.sh` §2 — by design)
 4. **Empirical dial-in test (the decisive check).** From the VM over the
   live reverse tunnel, with `/home/hatch` still `2770` (group-writable):
   `ssh -p 2226 root@127.0.0.1` with agent-forwarded `id_frontdoor`
   → `DIALIN_OK`, `whoami` → `root`. Public-key dial-in on 2226
   **works with zero changes**.
 ## Verdict
 Neither proposed remediation is required or was applied:
 - `chmod g-w /home/hatch` — unnecessary for SSH (path not consulted);
  would also alter the setgid shared-directory semantics for no benefit.
 - `StrictModes no` in sshd config — unnecessary, and would weaken
  authentication security globally.
 The StrictModes denial described in #215 cannot occur for the actual
 login path. No sshd reload was needed (no config changed).
 ## Adjacent real gap (flagged, not fixed — needs a decision)
 `super@bl`'s ed25519 key (`SHA256:UOeqKF5B…`) lives only in
 `/home/hatch/.ssh/authorized_keys`, which sshd **never reads** (no
 `hatch` user exists). If super needs 2226 dial-in, that key must be
 appended to `/root/.ssh/authorized_keys`. The recover script
 deliberately installs only 646's own keys there, so this is a
 provisioning decision for 646/super — left untouched.
 Fixes #215