On msb, a host allowed by a kit's caps.network.allow is reachable over HTTPS but not over SSH: outbound :22 to the same host times out, so git clone/git push over SSH fail even though the host is explicitly allowed and the forwarded ssh-agent is working. The same kit on sbx carries SSH fine.
Repro (quickstart main 1862b05, msb 0.6.15, ACQ_NETWORK_TIER=balanced default)
Our team kit allows gitlab.login.gov (it serves both glab/HTTPS and SSH push in our sbx sandboxes). In an msb sandbox created with the kit:
$ msb exec <sandbox> -u agent -e HOME=/home/agent -e SSH_AUTH_SOCK=/home/agent/.acq/ssh-agent.sock -- sh -c 'ssh-add -l | head -1; ssh -T -o ConnectTimeout=8 git@gitlab.login.gov 2>&1 | head -2'
256 SHA256:... (ED25519) <- forwarded agent works
Connection timed out during banner exchange <- :22 egress blocked
Connection to 54.186.45.133 port 22 timed out
HTTPS egress to allowed hosts works in the same sandbox (the playbook and USAi kit fetches succeed), so this is specifically the port dimension of the allow rule, not name resolution or the allowlist itself.
Why it matters
ADR-0021 built host ssh-agent forwarding precisely so git-over-SSH works in msb sandboxes — but without :22 egress to the kit's allowed hosts, the forwarded agent is stranded: signing works, push doesn't. Any team whose git remote is SSH (ours: git@gitlab.login.gov) loses the push path on msb while keeping it on sbx, which undercuts kit portability between the backends.
Suspected shape
The kit allow@host emission appears to cover the HTTP(S) ports only; nothing emits tcp:22 for kit hosts under the deny-default tiers. sbx doesn't have the gap because its proxy/policy layer passes SSH for allowed domains.
Suggested fix
Emit tcp:22 alongside the HTTP(S) rules for kit-allowed hosts (matching sbx's effective behavior), or — if blanket :22 is too broad — add a neutral way for a kit to say a host needs SSH (e.g. host:22 entries in caps.network.allow, which the sbx side can ignore or map). Either way the two backends should agree on what "allowed" means for a git remote.
Environment
quickstart main 1862b05, msb 0.6.15, macOS (Apple Silicon) host, balanced tier. Found during a two-backend portability test of our team kit (same kit, both backends, same day).
On msb, a host allowed by a kit's
caps.network.allowis reachable over HTTPS but not over SSH: outbound:22to the same host times out, sogit clone/git pushover SSH fail even though the host is explicitly allowed and the forwarded ssh-agent is working. The same kit on sbx carries SSH fine.Repro (quickstart main
1862b05, msb 0.6.15,ACQ_NETWORK_TIER=balanceddefault)Our team kit allows
gitlab.login.gov(it serves bothglab/HTTPS and SSH push in our sbx sandboxes). In an msb sandbox created with the kit:HTTPS egress to allowed hosts works in the same sandbox (the playbook and USAi kit fetches succeed), so this is specifically the port dimension of the allow rule, not name resolution or the allowlist itself.
Why it matters
ADR-0021 built host ssh-agent forwarding precisely so git-over-SSH works in msb sandboxes — but without
:22egress to the kit's allowed hosts, the forwarded agent is stranded: signing works, push doesn't. Any team whose git remote is SSH (ours:git@gitlab.login.gov) loses the push path on msb while keeping it on sbx, which undercuts kit portability between the backends.Suspected shape
The kit
allow@hostemission appears to cover the HTTP(S) ports only; nothing emitstcp:22for kit hosts under the deny-default tiers. sbx doesn't have the gap because its proxy/policy layer passes SSH for allowed domains.Suggested fix
Emit
tcp:22alongside the HTTP(S) rules for kit-allowed hosts (matching sbx's effective behavior), or — if blanket:22is too broad — add a neutral way for a kit to say a host needs SSH (e.g.host:22entries incaps.network.allow, which the sbx side can ignore or map). Either way the two backends should agree on what "allowed" means for a git remote.Environment
quickstart main
1862b05, msb 0.6.15, macOS (Apple Silicon) host, balanced tier. Found during a two-backend portability test of our team kit (same kit, both backends, same day).