Runner: SSH identity on Sergeys-Mac-mini resolves to a deploy key, breaking git clone over SSH

[serge-ivo]

Problem

On the runner node Sergeys-Mac-mini.local, the SSH key presented to GitHub authenticates as jobsearch-works/shared — a repository deploy key, not the user's account. Any git clone git@github.com:... for a private repo outside that one repository therefore fails with "Repository not found", which is GitHub's generic message for "authenticated, but this identity cannot see it". The failure is misleading: it looks like the repo is missing when it is really a wrong-identity problem.

Observed

Cloning proappstore-online/school-clubs over SSH failed this way. The same clone succeeded immediately via gh repo clone over HTTPS, which uses GITHUB_TOKEN and authenticates as serge-ivo, an identity that can see the repo.

Consequence

Two different GitHub identities are active on the same machine depending on transport: a narrow deploy key over SSH and a broad user token over HTTPS. Any coding run that happens to use an SSH remote will silently get the wrong, much weaker identity. Existing checkouts with SSH remotes may fail to fetch or push for reasons that appear to be missing repositories.

Suggested Work

• Audit which identity each transport resolves to on every registered runner node.
• Decide and document the intended identity for agent git operations.
• Surface the effective git identity in coding_diagnostics so this is visible without a failed clone, and consider reporting it per transport.
• Where a deploy key is genuinely wanted, scope it to the repo that needs it rather than leaving it as the default SSH identity.

Related

This is adjacent to the credential-scope concerns in #676: the credential an agent actually operates with is not currently visible before it is used.

Cross-reference #676.

[serge-ivo]

Code fix shipped — commit a1b71d5

What was implemented

Runner (packages/browser-runner/src/coding/repo.ts):

• Added parseSshIdentity(raw) — pure function that parses the GitHub SSH welcome banner (Hi <name>! You've...) to extract the authenticating identity. Deploy keys arrive as <org>/<repo> (a slash is the structural marker); user accounts are bare login names. 5 unit tests pin the discriminator.
• Added probeGitSshIdentity(host) — calls ssh -T -o BatchMode=yes -o ConnectTimeout=5 git@<host> and returns { checked, host, identity, isDeployKey, raw }.

Runner server (packages/browser-runner/src/server.ts):

• Added /coding/git-identity endpoint — calls probeGitSshIdentity("github.com") and returns the result.

API diagnostics (workers/api/src/routes/coding-diagnostics.ts):

• coding_diagnostics now calls /coding/git-identity on the runner (alongside /health and /coding/diagnostics) and includes the result as gitIdentity in the response.
• When isDeployKey: true + SSH repos exist → emits a warn issue naming the affected repos and explaining that a deploy key authenticates to exactly one repository.
• When authentication failed entirely + SSH repos exist → emits a warn issue.
• The probe only runs when a runner is connected and is a real SSH connection to github.com, so instances with no SSH repos see no added latency.

Owner machine action still required

The code fix makes the problem visible without a failed clone. The underlying cause on Sergeys-Mac-mini.local is that ~/.ssh/config routes github.com to a deploy key for jobsearch-works/shared rather than to the user account serge-ivo. Opening coding_diagnostics for any instance on that machine (with SSH-URL repos) will now show:

SSH identity on this machine is a deploy key (jobsearch-works/shared) — not a user account. Repos cloning over SSH: "...". A deploy key authenticates to exactly one repository; private repos outside that one will fail with "Repository not found".

To fix the machine: check ~/.ssh/config for a Host github.com stanza that points to the deploy key. Either remove it (if the deploy key is no longer needed), add a Host github-deploy alias for it (so github.com resolves to the user key), or re-add the affected repos in the Coder console using HTTPS clone URLs so the platform can inject a token.

Closes #684 for the code half. Machine config fix is out of scope for a code push.