RunPod pods cannot authenticate with the configured SSH key

[morluto]

Summary

With provider: runpod, Crabbox can create a pod that reaches RUNNING and exposes a public TCP mapping for port 22, but SSH key authentication fails even when ssh.key points to a private key with a valid adjacent .pub file.

In two Crabbox 0.38.0 provisioning attempts, the created pods exposed port 22 but reported PUBLIC_KEY as the literal string null. SSH readiness could not authenticate with the configured key.

Reproduction

Configure a RunPod provider and a local SSH key:

provider: runpod
ssh:
  key: /path/to/id_ed25519

Ensure /path/to/id_ed25519.pub exists, then create a RunPod lease:

crabbox warmup --provider runpod --keep

The pod reaches RUNNING with a public port 22 mapping, but the configured key is not authorized and SSH readiness cannot complete.

Root cause

The RunPod acquire path sets StartSSH: true on its internal deploy input, but that field is not serialized by runpodDeployPayload. The configured ssh.key is only used later by the local SSH client; its public half is never added to the POST /pods request.

The request therefore has no env.PUBLIC_KEY value:

ssh.key -> local SSH identity
        \-> (missing) POST /pods env.PUBLIC_KEY

RunPod's official container startup script only appends PUBLIC_KEY to ~/.ssh/authorized_keys and starts SSH when that value is present:

https://github.com/runpod/containers/blob/0e47720fce6ccf75703e5f5068e90dc817492ae7/container-template/start.sh

The RunPod REST API supports an env object on pod configuration:

https://docs.runpod.io/api-reference/pods/POST/pods

This makes the failure deterministic at the request boundary: a configured Crabbox key cannot become an authorized pod key because its public value is absent from the deploy payload.

Expected behavior

Before creating a paid pod, Crabbox should read the public half of the configured SSH key and fail clearly if it is missing or empty. The RunPod deploy request should serialize that value as env.PUBLIC_KEY, allowing the official image to populate authorized_keys and start SSH for the same identity Crabbox uses locally.

Impact

Affected RunPod leases can consume provisioning time and reach a nominally running state while remaining unusable to Crabbox's SSH transport. Exporting PUBLIC_KEY in the caller's shell does not repair this path because the provider constructs the pod environment explicitly.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 31, 2026, 11:20 AM ET / 15:20 UTC.

Summary
This issue remains necessary because the same-author repair PR at #1203 is still open and explicitly owns the reported RunPod SSH-key path. Its supplied redacted live-provider transcript is positive evidence, but the review sandbox could not execute even read-only repository inspection, so current-main implementation and history could not be independently confirmed.

Reproducibility: unclear. the report and linked PR describe a concrete live RunPod reproduction and a successful after-fix run, but this review could not execute the current-main reproduction or inspect its source path because the read-only sandbox failed.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
An open same-author PR already owns this narrow repair, so another fix PR would duplicate active contributor work.

Review details

Best possible solution:

Review and land the focused linked repair if its current diff preserves existing RunPod compatibility; after merge, close this issue through the linked relationship and verify the released behavior.

Do we have a high-confidence way to reproduce the issue?

Unclear: the report and linked PR describe a concrete live RunPod reproduction and a successful after-fix run, but this review could not execute the current-main reproduction or inspect its source path because the read-only sandbox failed.

Is this the best way to solve the issue?

Yes in principle: passing the configured public half in the explicit RunPod pod environment and failing before paid provisioning when it is absent is a narrow repair; the still-open PR must be reviewed against current main before that conclusion becomes merge-ready.

AGENTS.md: unclear because the file could not be read completely.

Remaining risk / open question:

• The linked PR has not merged, so closing this issue would remove the canonical bug report before the current-main fix and upgrade behavior can be verified.
• Read-only sandbox failure prevented independent confirmation of the current implementation, tests, release inclusion, and RunPod-area ownership history.

Codex review notes: model internal, reasoning high; reviewed against 5aa1c3983874.

Label changes

Label changes:

• add issue-rating: 🦐 gold shrimp: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.
• remove issue-rating: 🐚 platinum hermit: Current issue advisory state no longer selects this label.
• remove clawsweeper:needs-live-repro: Current issue advisory state no longer selects this label.

Label justifications:

• P2: A RunPod-specific provisioning path can create a paid but unusable lease, a concrete normal-priority provider regression with limited blast radius.
• impact:auth-provider: The reported failure prevents the configured SSH identity from being authorized for the provider-created pod.

Evidence reviewed

What I checked:

• Open linked implementation candidate: The provided GitHub context shows fix(runpod): make new pods accept the configured SSH key #1203 remains open, uses closing syntax for this issue, and describes the exact public-key propagation repair; an open implementation PR is not a safe reason to close the issue before merge. (6df3811bd8fe)
• Reported live behavior and proposed live proof: The issue gives a concrete RunPod provisioning path, while the linked PR reports a redacted successful lease, SSH readiness, repository sync, and remote command plus a missing-sidecar preflight check. This supports keeping the issue paired with the active PR rather than creating duplicate repair work. (1a3b1aabb466)
• Repository inspection unavailable: The required read-only command to read AGENTS.md, search the RunPod implementation, inspect status, and run the maturity helper failed before execution with bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted; therefore no current-main source, test, history, release, or maturity claim is made from the checkout.

Likely related people:

• morluto: Reported the concrete RunPod request-boundary failure and authored the currently open PR that explicitly implements the narrowly described repair; current-main feature-history ownership could not be inspected because read-only commands failed. (role: reporter and active repair author; confidence: low; commits: 6df3811bd8fe, 1a3b1aabb466; files: internal/providers/runpod)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.