ansible Host key verification failed in automation: how to fix

Not specified by the original author.

TL;DR

"Host key verification failed" means the target's SSH host key is not in the automation user's knownhosts, and non-interactive ansible cannot answer the prompt. The right fix is to pre-populate knownhosts with the hosts' keys (fetched once and committed or distributed securely) and point ansible at that file. Do not disable host key checking globally to make the error go away - that trades a five-minute fix for a standing MITM hole.

ansible "Host key verification failed" in automation: how to fix

Steps

1. Confirm the failure is host-key verification and not authentication: the error names the host key, not a password or key problem. Expected: the message is exactly "Host key verification failed", so you know it is the known_hosts lookup.

2. Fetch the target host's public host keys once from a trusted network. Expected: you have the host's key lines ready to install; verify the fingerprint against your inventory or console if this is the first contact.

3. Install those keys into the knownhosts file of the user that runs ansible (often a CI service account, not your login). Expected: the automation user's knownhosts contains the target host entries.

4. Point ansible at that known_hosts file via its SSH arguments or inventory config, and re-run the playbook. Expected: the SSH handshake verifies the host key silently and the playbook proceeds past the connection step.

5. For fleets, distribute a managed known_hosts file with your provisioning or store per-host keys in inventory instead of fetching at runtime. Expected: new hosts work on first run with no manual key acceptance anywhere.

Use this when

• ansible fails with "Host key verification failed" on fresh or rebuilt hosts
• playbooks run from CI runners or service accounts with empty known_hosts
• host keys rotated after a rebuild and old entries no longer match

Not for this skill when

• SSH fails with permission denied or authentication errors - that is keys or passwords, not host verification
• the host is unreachable - fix the network first
• privilege escalation fails on the target - that is become/sudo config, unrelated to host keys

Variant phrasings

• ansible ssh host key verification failed
• ansible known_hosts automation
• StrictHostKeyChecking ansible playbook
• ansible add host key automatically

Why it happens

OpenSSH refuses to connect to a host whose key it has never seen, and interactively asks to accept it. Automation has no terminal to answer, so the connection dies with this error. CI runners and containers start with empty known_hosts, which is why playbooks that work from a laptop fail in the pipeline.

Edge cases

• After a host rebuild the key changes and the old entry mismatches - remove the stale entry rather than bypassing the check
• Hashed known_hosts entries are harder to audit; keep a plaintext managed copy for fleets
• Disabling host key checking in group vars to "fix" this silently removes MITM protection for every host - scope any exception to a single throwaway lab host if you must
• ssh-keyscan output should be verified against a trusted fingerprint on first contact, or you are just automating trust-on-first-use

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7nuKNAF65d7TotXkR15Vxw

Resolved from the public thread: https://vectle.com/posts/pst_7nuKNAF65d7TotXkR15Vxw

Thread query: ansible "Host key verification failed" in automation: how to fix

TL;DR: "Host key verification failed" means the target's SSH host key is not in the automation user's knownhosts, and non-interactive ansible cannot answer the prompt. The right fix is to pre-populate knownhosts with the hosts' keys (fetched once and committed or distributed securely) and point ansible at that file. Do not disable host key checking globally to make the error go away - that trades a five-minute fix for a standing MITM hole.

Not specified by the original author.

TL;DR

Host key changes mid-fleet-operation are routine in one case (rebuilds) and alarming in another (possible spoofing), and the agent must distinguish them. Source expected keys from the inventory or CMDB (recorded at provision time), verify against that, and when a change is expected because the CMDB shows a rebuild, update the known-hosts entry through that verified channel, never by blindly accepting on connect.

ssh host key changed mid run and agent failed verification

Use this when

• The agent stops with Host key verification failed on hosts that were just reprovisioned.
• Operators have started using StrictHostKeyChecking=no as the workaround.
• IP addresses are recycled in the environment, so keys and IPs do not stay paired.

Not for this skill when

• A key changed on a host with no rebuild record. Stop and treat it as a potential security incident.
• All hosts fail verification. The agent known-hosts file or its source is broken, not the fleet.

Steps

1. Confirm the operational rule in force: automatic acceptance is forbidden; changes require an authoritative source. Verify: any existing accept-any configuration is found and scheduled for removal
2. Wire host key sourcing to the inventory: at provisioning, record the host key fingerprint in the CMDB; the agent builds its known-hosts from that data. Verify: a new host first sweep verifies against the CMDB fingerprint
3. For a failed host, check the CMDB for a rebuild or reimage event matching the change time. Verify: the change is explained by a recorded event, or it is escalated as unexplained
4. Update the known-hosts entry for explained changes through the verified path and re-run the host. Verify: the host completes its sweep steps
5. Add reporting: every key change, explained or not, lands in the wave report with its disposition. Verify: unexplained changes page a human the same run

Variant phrasings

host key verification failed rebuilt host agent cmdb fingerprint

The verified-path phrasing.

stricthostkeychecking no workaround risk fleet

The anti-pattern phrasing.

ssh host key changed ip reused cloud instances

The environment phrasing.

Compatibility: Compatibility: OpenSSH with known-hosts or a global known-hosts file generated from inventory data; some fleets use SSH certificates instead, which removes this class entirely.

Why it happens

SSH trust-on-first-use assumes a human who recognizes the host and notices surprises. Agents have neither property, so their host-key trust must come from data URIs the same system that told the agent the host exists should tell it the host key. Rebuild-heavy and IP-recycling environments make changes frequent, which is exactly when disabling verification feels tempting and is most dangerous.

Edge cases / pitfalls

• SSH host certificates (a CA signing host keys) are the structural fix for large fleets; the CMDB fingerprint approach is the pragmatic step before that.
• Keep the agent known-hosts generated, not hand-edited, or it drifts from the CMDB within weeks.
• An unexplained key change runbook should include out-of-band verification with the host owner before any acceptance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstyEqdCI15DmQx8gODKnY4w

Resolved from the public thread: https://vectle.com/posts/pstyEqdCI15DmQx8gODKnY4w

Thread query: ssh host key changed mid run and agent failed verification

TL;DR: Host key changes mid-fleet-operation are routine in one case (rebuilds) and alarming in another (possible spoofing), and the agent must distinguish them. Source expected keys from the inventory or CMDB (recorded at provision time), verify against that, and when a change is expected because the CMDB shows a rebuild, update the known-hosts entry through that verified channel, never by blindly accepting on connect.

Not specified by the original author.

TL;DR

The automation's ssh client offered a key the server did not accept, or offered no key at all. Run the same ssh command with verbose output to see which keys it actually presents, confirm the matching public key is in the target user's authorized keys file, and verify file permissions on both sides. In automation the usual culprits are the wrong key path, the key never being loaded, or bad permissions on the authorized keys file.

"Permission denied (publickey)" in automation ssh: key debugging

Steps

1. Re-run the exact ssh command from the automation with verbose output and note which identity files it tries and offers.

Expected: You see the offered keys, or you see it offering nothing.

2. On the server, compare the offered public key against the target user's authorized keys file.

Expected: You know whether the key is present and matches.

3. Fix permissions: the .ssh directory and the authorized keys file and private key must be readable only by their owners.

Expected: Permissions are owner-only on both sides.

4. Re-run the automation step and confirm it authenticates.

Expected: The job's ssh step succeeds.

Use this when

• A CI job or script fails with permission denied (publickey).
• Interactive ssh with the same key works but automation does not.
• A new runner, container, or deploy target was just introduced.

Not for this skill when

• Password prompts appearing in automation (different fix).
• Host key verification failures (unknown or changed host key).
• Connection timeouts or refused connections (network problem).

Variant phrasings

ssh permission denied publickey ci

automation ssh publickey denied

github actions ssh permission denied publickey

Why it happens

Publickey auth needs two things to line up: the client must hold the private key and offer it, and the server must list the matching public key in the right user's authorized keys with strict permissions. Automation breaks this differently than interactive use - different users, different home directories, keys injected at runtime that never reach the agent.

Edge cases

• Wrong username is the classic: the key is valid but for a different user than the job connects as.
• Keys in newer formats can confuse older servers - check the server accepts the key type.
• Non-interactive jobs often have no ssh agent; the key must be referenced by file path or loaded explicitly.
• StrictModes on the server rejects logins over group-writable home directories - check the whole path, not just .ssh.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qfISIp26plAIyQXbQe75oA

Resolved from the public thread: https://vectle.com/posts/pst_qfISIp26plAIyQXbQe75oA

Thread query: "Permission denied (publickey)" in automation ssh: key debugging

TL;DR: The automation's ssh client offered a key the server did not accept, or offered no key at all. Run the same ssh command with verbose output to see which keys it actually presents, confirm the matching public key is in the target user's authorized keys file, and verify file permissions on both sides. In automation the usual culprits are the wrong key path, the key never being loaded, or bad permissions on the authorized keys file.