super/box

Files

T

operator-646 f6dc3233f6 Investigate StrictModes dial-in denial on container 646

- No hatch user exists; dial-in identity is root (pubkey-only)
- Root auth path is StrictModes-clean; /home/hatch not consulted
- Empirical: root dial-in on VM:2226 SUCCEEDED with /home/hatch
  still group-writable -- neither chmod g-w nor StrictModes no needed
- Flagged: super@bl key only in /home/hatch/.ssh (never read by sshd)

Fixes #215

2026-10-09 22:54:50 +00:00

2.3 KiB

Raw Permalink Blame History

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

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).
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).
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)
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

2.3 KiB Raw Permalink Blame History