fix: trust new ssh hosts on first connection#42
Merged
Conversation
On a fresh runner, the user's known_hosts doesn't contain the git host yet, so `git clone` fails with "Host key verification failed" before the action can claim the lock. Setting GIT_SSH_COMMAND with StrictHostKeyChecking=accept-new tells ssh to auto-accept a new host key (and pin it thereafter), which removes the need for callers to pre-seed known_hosts. Works for any git_uri host — github.com, gitlab, self-hosted — without URI parsing. Symptom seen in https://github.com/sandipndev/build/actions/runs/24690001595 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On a fresh GitHub Actions runner (classic or self-hosted), the runner user's
~/.ssh/known_hostsdoesn't yet contain the host ingit_uri, sogit clonefails with:…before the action can acquire the lock. Seen in the wild: https://github.com/sandipndev/build/actions/runs/24690001595.
Every consumer currently has to add an
ssh-keyscanstep before calling the action, which defeats the point of a drop-in locking primitive.Fix
Export
GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=accept-new"in both the main and post scripts.accept-newauto-accepts a new host key on first connection and pins it thereafter, so subsequent connections are verified normally. No URI parsing needed — works forgithub.com, GitLab, self-hosted, anything.Requires OpenSSH ≥ 7.6 (2017) — universally available on modern runners.
Test plan
ssh-keyscanworkaround in that PR can then be reverted.🤖 Generated with Claude Code