Support secure SSH access for Linux jobs

[jamiemonserrate]

Description

Add Linux hosted-job support to bk job ssh using Namespace's TCP container endpoint with SSH host-key verification.

The CLI consumes the transport and ssh.host_keys fields from the existing SSH session endpoint. Raw TCP sessions require at least one valid host key and fail closed if verification cannot be performed.

Existing macOS jobs continue using authenticated Namespace WSS ingress. If host keys are supplied for ingress sessions, the CLI verifies those too.

Context: A-1682

Changes

• Handle tcp and namespace_ingress SSH transports explicitly.
• Strictly validate TCP endpoint URLs.
• Accept multiple host keys to support key rotation.
• Verify the server's presented key against the API-provided keys.
• Reject TCP sessions with missing or malformed host keys before dialing.
• Keep the Namespace access token off raw TCP connections.
• Update command help to refer to hosted jobs rather than only macOS jobs.
• Add end-to-end coverage for TCP sessions, rotated keys, mismatches, malformed responses, and existing ingress behavior.

Deployment

Deploy the corresponding Buildkite API changes before relying on Linux SSH sessions. The CLI will fail closed if a TCP response does not include valid host keys.

Rollback

Reverting this change restores the previous WSS-only behavior. Linux TCP sessions will be rejected, while existing macOS SSH sessions remain supported.

Testing

• Tests have run locally (go test ./...)
• Code is formatted
• Focused tests pass with the race detector
• SSH tests pass across 10 repeated runs
• golangci-lint passes
• The job package cross-compiles for Windows
• govulncheck ./... reports no called vulnerabilities

Disclosures / Credits

Implemented with Codex. Codex gathered the linked Linear, Slack, Notion, Namespace API, and prior PR context; implemented the CLI transport and host-key verification changes; and added and ran the automated coverage. Jamie reviewed the plan, API alignment, and resulting implementation.

[buildsworth-bk-app]

I didn't find a concrete issue in this pass. This changes SSH server authentication and host-key verification, so I'm leaving a comment rather than approving under the L1 ceiling.

Want to dig deeper?

Paste this into your agent to explore the findings from this review's Buildkite build:

Download the buildsworth logs from build 18968, then answer my questions about the findings.

Install the reading-buildsworth-logs skill to run this.

About buildsworth

Model: gpt-5.6-sol with xhigh thinking.

How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.

Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. Unless repository policy already allows L2 approval, grant it by mentioning @buildsworth-bk (see approval ceiling and L2 approval grant):

• L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
• L2 — Standard risk (new UI, additive API fields, refactors). Approved only when repository policy or a verified grant allows it; otherwise comment-only.
• L3 — High risk (auth, migrations, payments, secrets, perf-critical paths). Human review always required.