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
This commit is contained in:
@@ -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
|
||||||
Reference in New Issue
Block a user