# 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