Fix Ansible Missing sudo password and Host key verification failed

Why this step matters

The two literal errors identify different phases. Separating them prevents unsafe advice such as disabling host checking to solve a sudo password or changing sudoers to solve an SSH trust failure.

What to understand

Record the control-node hostname, UTC time, Ansible version, Git revision, inventory path, target pattern, limit, and task name.

Keep each target separate. One host can fail host verification while another reaches sudo and reports Missing sudo password.

Sanitize addresses, usernames, filesystem paths, and any variable values before sharing evidence.

If the playbook performs changes before the failing task, reproduce with a diagnostic play or check mode instead of replaying production mutations.

System changes

• No intended remote change; this step collects or validates evidence.

Syntax explained

-i {{inventoryPath}}

Selects the authoritative inventory source rather than an implicit default.

--limit {{targetHost}}

Restricts evidence collection to the reviewed host or group.

--start-at-task

Starts at the named task; use only when earlier tasks are not required to establish safe state.

-vv

Shows connection context and failure phase without the highest-volume secret exposure of -vvvv.

Why this step matters

A correct fix applied to the wrong host, user, port, identity, or environment is still an incident. Inventory proof anchors every later SSH and sudo conclusion.

What to understand

Confirm inventory_hostname separately from ansible_host; the first is Ansible's logical name and the second is the connection address.

Confirm the connection plugin is ssh for this procedure. Paramiko, network_cli, WinRM, and local connections have different host-key and privilege behavior.

Use ansible-config dump --only-changed to identify configuration overrides without dumping secrets.

Treat extra vars as highest-precedence inputs and inspect the original runner command or job template for hidden overrides.

System changes

• No intended remote change; this step collects or validates evidence.

Syntax explained

--graph

Shows groups and selected hosts without contacting managed nodes.

--host {{targetHost}}

Shows the merged variables Ansible resolved for one inventory hostname.

Why this step matters

Reading the file first preserves evidence and identifies hostname, address, and nonstandard-port forms that OpenSSH hashes or records separately.

What to understand

Run as the same operating-system account and HOME used by the Ansible process; service accounts and CI containers often have different known_hosts files.

Check system-wide known_hosts and SSH config only if the runner is configured to use them.

For hashed entries, ssh-keygen -F can search without revealing every hostname.

Record the old fingerprint with ssh-keygen -lf on a protected copy when incident policy requires comparison.

System changes

• No intended remote change; this step collects or validates evidence.

Syntax explained

-F

Searches known_hosts for a hostname or bracketed host-and-port token.

-f {{knownHostsPath}}

Selects the exact file used by the automation process instead of assuming the interactive user's default.

Why this step matters

The network can show which key a server presents, but only an independent channel can establish that the key belongs to the intended server.

What to understand

Prefer the modern Ed25519 fingerprint when supported, while retaining any approved fallback algorithm required by policy.

Compare exact SHA256 fingerprints character for character and record who verified them, by which channel, and at what UTC time.

If the host was rebuilt, confirm the change ticket, instance identity, IP assignment, and first-boot host-key generation record.

If DNS points to several legitimate nodes, manage each identity explicitly or use host certificates rather than accepting whichever key answers first.

System changes

• No intended remote change; this step collects or validates evidence.

Syntax explained

-T 5

Limits collection time so a stale or filtered address does not stall the procedure.

-p {{sshPort}}

Contacts the inventory-selected SSH port.

-t ed25519,rsa

Requests explicit supported host-key algorithms for fingerprint comparison.

ssh-keygen -lf -

Reads collected public keys from standard input and prints SHA256 fingerprints.

Why this step matters

A narrow, reversible update restores trust while preserving proof of the previous key and leaving global verification controls intact.

What to understand

Use the bracketed host:port form for nonstandard ports and the plain hostname only for port 22.

Install the exact verified line from the protected collection artifact; do not perform a fresh unauthenticated scan during the write.

Preserve file owner, mode, and parent directory permissions for the automation account.

For fleets, prefer ansible.builtin.known_hosts with reviewed key material or an OpenSSH host CA rather than editing runner images manually.

System changes

• Creates a timestamped backup and removes one reviewed known_hosts token; adding the new key changes the automation account's trust store.

Syntax explained

ssh-keygen -R

Removes entries for exactly the supplied hostname token.

-f {{knownHostsPath}}

Updates the reviewed trust file rather than an implicit user file.

Why this step matters

Privilege escalation is downstream from transport. A clean unprivileged proof prevents sudo troubleshooting from masking wrong keys, users, inventory, Python, or connection plugins.

What to understand

The ping module is not ICMP; it transfers and executes a small Python module on the managed node.

Use -e ansible_become=false only for this diagnostic override and remove it from normal runs.

If SSH reports Permission denied (publickey), follow /guides/troubleshoot-ssh-permission-denied-publickey.

If Python is absent, bootstrap or select the supported interpreter through a separate reviewed procedure.

System changes

• No intended remote change; this step collects or validates evidence.

Syntax explained

-m ansible.builtin.ping

Runs Ansible's read-only connection and Python capability test.

-e ansible_become=false

Disables become only for this diagnostic so SSH can be proven independently.

-vv

Shows connection selection without maximum debug output.

Why this step matters

sudo -n -l reveals whether the account is authorized and whether a password is expected without consuming or exposing a password.

What to understand

A password-required result can be correct policy for interactive operator runs and incompatible with unattended CI unless a secret broker is configured.

A user-not-allowed result is authorization failure, not a missing credential; adding a password will not grant rights.

Review command aliases, Runas targets, environment restrictions, requiretty, and included sudoers files through the policy owner.

Test the exact remote user from inventory; sudo policy is account-specific.

System changes

• No intended remote change; this step collects or validates evidence.

Syntax explained

ansible.builtin.command

Executes argv without an extra shell on the managed node.

sudo -n

Uses noninteractive mode and fails rather than prompting.

sudo -l

Lists the invoking user's permitted commands and authentication requirements.

ansible_become=false

Prevents Ansible from trying privilege escalation around the diagnostic.

Why this step matters

An interactive prompt keeps the become password out of command history and plaintext inventory while proving the expected sudo path.

What to understand

Use -b to enable become and -K to request its password; they are independent flags.

Ansible uses one prompted become password for all hosts in the run, so do not mix accounts with different credentials.

Limit the test to id -u and expect the numeric identity of the approved become user.

Cancel if the prompt or target differs from expectations; never type the password into a recorded terminal.

System changes

• sudo authentication is attempted and may update normal authentication logs; the id command does not change managed state.

Syntax explained

-b / --become

Enables privilege escalation for the module execution.

-K / --ask-become-pass

Prompts locally for the privilege-escalation password; it does not enable become by itself.

-a 'id -u'

Runs a bounded identity check rather than the original state-changing play.

Why this step matters

Encrypted variables or controller-managed credentials support noninteractive jobs without committing the cleartext sudo password.

What to understand

Enter the secret through standard input or an approved prompt, not as a positional shell argument.

Store vaulted variables in a restricted group_vars or host_vars file appropriate to the smallest host set.

Supply the Vault unlock secret through an approved prompt, credential manager, or executable client; a plaintext password file merely moves the secret.

Use no_log on tasks that could echo secret-bearing parameters, and review third-party roles and callback plugins.

System changes

• Creates encrypted Vault ciphertext for a variable; no managed-node policy is changed.

Syntax explained

encrypt_string

Encrypts one variable value for inclusion in structured Ansible data.

--vault-id {{vaultId}}@prompt

Labels the ciphertext and prompts for the Vault encryption password.

--stdin-name ansible_become_password

Reads the cleartext from standard input and names the encrypted variable without putting the secret in argv.

Why this step matters

A convergent limited check demonstrates that the repaired credentials and policy support the intended role without immediately changing the fleet.

What to understand

Read each changed prediction and diff; redact configuration secrets before attaching output.

Confirm unreachable and failed are zero and no host outside the explicit limit appears.

Investigate skipped tasks whose check-mode behavior hides a required privileged command.

Use serial execution and normal approvals for the later real run.

System changes

• No intended remote change; this step collects or validates evidence.

Syntax explained

--check

Asks supporting modules to predict changes without applying them.

--diff

Shows supported before/after content; output may be sensitive.

--limit {{targetHost}}

Constrains validation to the reviewed canary.

--vault-id

Supplies the approved Vault identity without placing the secret on the command line.

Why this step matters

The first run proves the intended operation and the second establishes idempotency. Capturing trust and privilege metadata makes a future rotation or rebuild diagnosable.

What to understand

Scale beyond the canary only through the normal serial, approval, monitoring, and rollback policy.

Version verified host keys or host CA trust in the runner image or configuration system.

Test credential retrieval and sudo policy before deployment windows without printing the secret.

Alert separately on host-key changes, SSH authentication failures, and become failures because they have different owners and severity.

System changes

• The approved playbook may apply its reviewed changes to the canary; the repeat check should predict none.

Syntax explained

first playbook run

Executes the approved canary operation through the normal credential and trust path.

repeat --check --diff

Verifies convergence and captures evidence of unexpected drift.