ssh -o StrictHostKeyChecking in CI Pipelines
StrictHostKeyChecking decides whether ssh prompts, accepts, or refuses a host whose key is not yet in known_hosts.
CI has no interactive prompt, so the default behavior either hangs or fails on a first connection. Knowing the safe and unsafe settings keeps deploys reliable without disabling verification blindly.
What it does
StrictHostKeyChecking governs ssh's response to an unknown or changed host key. "yes" refuses unknown hosts; "accept-new" (OpenSSH 7.6+) auto-adds new hosts but still rejects changed keys; "no" accepts and adds anything. The default "ask" prompts, which has no answer in CI.
Common usage
# safest non-interactive option: trust on first use, reject changes
ssh -o StrictHostKeyChecking=accept-new user@host
# fully unattended but unverified (avoid for production)
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host
# preferred: pre-seed the key so strict checking can stay on
ssh-keyscan host >> ~/.ssh/known_hosts
ssh user@hostOptions
| Value | What it does |
|---|---|
| accept-new | Add unknown hosts automatically; reject changed keys |
| yes | Reject any host not already in known_hosts |
| no / off | Accept and record any host key (no verification) |
| ask (default) | Prompt interactively; hangs in CI |
In CI
Prefer ssh-keyscan into known_hosts so StrictHostKeyChecking can stay at its strict default. If you must avoid the prompt directly, use accept-new rather than no: it still catches a swapped or man-in-the-middle host key on later runs.
Common errors in CI
Host key verification failed. means the host is unknown (default ask with no TTY) or its key changed. "No ECDSA host key is known for host and you have requested strict checking." names the missing key type; run ssh-keyscan for that host. "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" means the stored key no longer matches; remove the stale entry with ssh-keygen -R host before re-adding.