FootprintAI/Containarium

Goal By end of week, on a dev backend: containarium sessions terminate --user drops a user's open shells on every box they reach; containarium ssh rotate registers a new key with proof of possession and the old one keeps working through the overlap window; a cloud-enrolled backend forwards the authorization decision to the cloud. The OSS half B of the SSH live authorization design (#2515; architecture doc on PR #2514). Follows umbrella A (#2521). Gate: this sprint does not start until #2521's definition of done holds, with the #2520 e2e transcript linked there. Flow first: B optimizes a revocation path that A must first prove works. Public contribution welcome. Items labelled help wanted are buildable against generated stubs or a fake cloud; claim by commenting on the child issue. The spike (#2524) has no dependencies and can be picked up today. Phase 1 — make the flow work (this week) #2524 Spike: sshpiperd v1.6.1 partial-success into keyboard-interactive — unassigned, size:S (n

Part of the SSH live authorization design (#2515). Component 3 in docs/architecture/ssh-live-authorization.md (PR #2514). Blocked by the spike issue (see umbrella) and #2518. The cloud approval records and page (cloud half item 12) must exist for dev verification; unit-testable against a fake before then. What When Authorize returns APPROVAL_PENDING with an SSHDeviceApproval: Keyboard-interactive flow (if the spike says yes): return partial success; the challenge carries the instruction (Approve this device at <url>, code <code>) and one prompt; on answer or every poll_after, re-call Authorize with approval_id; ALLOW completes auth; APPROVAL_DENIED, expires_at, or 60 s cap → deny. Banner-only flow (if the spike says no): deny, with the URL and code in BannerCallback; the user approves and reconnects; the next connection is a cache hit or a fresh ALLOW. Certificate holders never enter this path. Approval identity is (user, fingerprint); the client address is recorded for audit only (

Part of the SSH live authorization design (#2515). The managed branch of component 4 in docs/architecture/ssh-live-authorization.md (PR #2514). Blocked by #2516 and #2517. The cloud RPC (cloud half item 10) must exist for the dev verification; unit-testable against a fake before then. What When the daemon is enrolled with a cloud, sshauthz.Decider forwards the request after the local-facts check instead of applying local policy. Local facts (jump account, orphan filter, collaborator row, box state) still run first and short-circuit with DENY NO_ACCESS; the cloud is never asked about a login the backend does not host. Forward AuthorizeSSHRequest unchanged over the existing host-bearer channel (internal/cloud/client.go, same auth context as Heartbeat), 2 s deadline. Return the cloud's response verbatim, including cache_ttl and approval. Cloud unreachable, deadline, or non-OK status → DENY UPSTREAM_UNAVAILABLE; the sentinel's grace rule (#2518) decides. No fallback to local policy. Mod

Part of the SSH live authorization design (#2515). The spike named in component 3 of docs/architecture/ssh-live-authorization.md (PR #2514). No dependencies; can start now. What Decide the vehicle for the device-approval prompt before the plugin path is scheduled. Using the real-sshpiperd harness in internal/sentinel/anondoor/integration_test.go, write a throwaway plugin whose PublicKeyCallback returns a partial-success (or whatever libplugin v1.6.1 offers) and whose KeyboardInteractiveCallback sends one instruction and one prompt, then completes auth. Try with a stock OpenSSH client: does the client see the instruction text, and does the session open after the answer? Record the outcome, the exact libplugin calls used, and any sshpiperd flags required, as a comment on this issue and a short note in the architecture doc. Done when A yes/no answer with a runnable test in the harness demonstrating it (kept as the integration test for the approval path if yes; kept as evidence if no).

Part of the SSH live authorization design (#2515). Component 6 in docs/architecture/ssh-live-authorization.md (PR #2514). Depends on the cloud challenge endpoint (cloud half item 11) for the live path; buildable and unit-testable against a fake server before it ships. What containarium ssh rotate [--name <device>] in internal/cmd/ssh.go: generate a new ed25519 keypair locally (internal/sshkey.Generate); POST /v1/user/ssh-keys:challenge → {challenge_id, nonce}; sign the nonce with the new private key; POST /v1/user/ssh-keys with {name, public_key, key_type, challenge_id, signature} under the user's bearer; the server verifies the signature before storing; rewrite ~/.containarium/ssh_config to the new key; keep the old private key file on disk; print the overlap window the server returned. Typed DTOs for the two endpoints next to the existing addSSHKeyReq, mirroring the cloud proto field-for-field (the existing pattern; see Deviations in the architecture doc). containarium login: a