🚨 Ansible Error Guide: 'Missing sudo password' / Incorrect sudo password

Overview

These two errors come from Ansible’s privilege-escalation (become) layer. When a task uses become: true, Ansible runs the module through sudo (or su, pbrun, etc.) on the remote host. If sudo prompts for a password and Ansible has none, you get Missing sudo password. If Ansible supplies a password that sudo rejects, you get Incorrect sudo password.

You will see one of these on the first escalated task:

fatal: [web-01]: FAILED! => {"msg": "Missing sudo password"}

fatal: [web-01]: FAILED! => {"msg": "Incorrect sudo password"}

The distinction matters: Missing means no password was provided and sudo wants one (no NOPASSWD rule, no --ask-become-pass). Incorrect means a password was provided but it is wrong for that user, or become_user/become_method is misconfigured.

Symptoms

• A task with become: true fails immediately; non-privileged tasks succeed.
• Running with --ask-become-pass (-K) makes it pass, confirming a password is required.
• Works for one host/user but not another (NOPASSWD configured inconsistently).
• Incorrect sudo password even though the password is right (wrong become_user or become_method).

ansible web-01 -i inventory.ini -b -m command -a 'whoami'

web-01 | FAILED! => {
    "msg": "Missing sudo password"
}

Common Root Causes

1. Sudo requires a password and none was supplied

The remote user has no NOPASSWD sudoers rule, and you did not pass a become password. sudo blocks waiting for input that never comes.

# this prompts for the become (sudo) password interactively
ansible web-01 -i inventory.ini -b --ask-become-pass -m command -a 'id'

BECOME password:
web-01 | CHANGED | rc=0 >>
uid=0(root) gid=0(root) groups=0(root)

If -K makes it work, the host simply needs a sudo password that you were not providing.

2. Wrong become password (Incorrect sudo password)

A password is supplied (via -K, ansible_become_password, or vault) but it does not match the remote account.

ansible-playbook -i inventory.ini site.yml --ask-become-pass

fatal: [web-01]: FAILED! => {"msg": "Incorrect sudo password"}

Verify the password manually on the host with the same user Ansible uses:

ssh deploy@10.0.4.21 'sudo -k; sudo -S id'   # then type the password

3. Wrong become_user or become_method

become_user defaults to root. If you escalate to a user whose password you typed for a different account, or use become_method: su when only sudo is allowed, the password is “incorrect”.

ansible-inventory -i inventory.ini --host web-01 | grep -i become

"ansible_become": true,
"ansible_become_method": "su",
"ansible_become_user": "root"

With su, Ansible needs root’s password, not deploy’s — a frequent source of Incorrect.

4. NOPASSWD sudoers rule missing or scoped too narrowly

The intended design was passwordless sudo, but the sudoers entry does not match the user, host, or command Ansible runs.

ansible web-01 -i inventory.ini -b --ask-become-pass -m shell -a 'sudo -l -U deploy'

User deploy may run the following commands on web-01:
    (ALL) /usr/bin/systemctl

deploy can only run systemctl without a password — any other module (e.g. apt) still demands a password and fails Missing sudo password.

5. become_pass in a vault that did not load

ansible_become_password lives in a vaulted var file, but the vault was not unlocked, so the value is empty and sudo sees no password.

ansible-playbook -i inventory.ini site.yml   # no --ask-vault-pass / vault id

fatal: [web-01]: FAILED! => {"msg": "Missing sudo password"}

ansible-vault view group_vars/all/vault.yml | grep ansible_become_password

6. sudo itself prompts unexpectedly (requiretty / lecture)

Older sudoers configs with Defaults requiretty or an interactive lecture can break non-interactive escalation, surfacing as a password/escalation error.

ansible web-01 -i inventory.ini -b --ask-become-pass -m shell -a 'grep -E "requiretty|lecture" /etc/sudoers /etc/sudoers.d/* 2>/dev/null'

/etc/sudoers:Defaults    requiretty

Diagnostic Workflow

Step 1: Confirm it is a become problem and whether a password is needed

ansible web-01 -i inventory.ini -b --ask-become-pass -m command -a 'id'

If -K fixes it, the host needs a sudo password. If it still fails with Incorrect, the password or become target is wrong.

Step 2: Inspect the become configuration in effect

ansible-inventory -i inventory.ini --host web-01 | grep -i become

Confirm ansible_become_method, ansible_become_user, and whether a password var is expected.

Step 3: Verify sudo rights on the host

ansible web-01 -i inventory.ini -b --ask-become-pass -m shell -a 'sudo -l'

Look for NOPASSWD: and whether the commands/modules you run are covered.

Step 4: Test the password and method manually

ssh deploy@10.0.4.21 'sudo -k; sudo -S whoami'   # paste the password when prompted

A manual sudo failure means the credential/method is the issue, not Ansible.

Step 5: Ensure the vault/password is actually loaded, then re-run

ansible-playbook -i inventory.ini site.yml --ask-vault-pass --ask-become-pass

Once the run succeeds with explicit prompts, move the secret into a vault and unlock it via vault_password_file for automation.

Example Root Cause Analysis

A previously-working playbook starts failing on a rebuilt host:

fatal: [app-05]: FAILED! => {"msg": "Incorrect sudo password"}

The same vault and password work on every other host. Checking the become config shows nothing unusual (sudo, become_user: root). Testing manually:

ssh deploy@10.0.5.5 'sudo -k; sudo -S id'

[sudo] password for deploy:
Sorry, try again.

The password Ansible holds is correct for the old deploy account. During the rebuild, the host was re-provisioned from a base image with a different deploy password, and the vault was never updated for this host. The credential is simply stale for app-05.

Fix: re-sync the deploy password (or, better, deploy a NOPASSWD sudoers drop-in for the automation user) and update the vault:

# preferred: passwordless sudo for the automation user, managed by Ansible
echo 'deploy ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/deploy
ansible-playbook -i inventory.ini site.yml --limit app-05

The escalated tasks now run without a password.

Prevention Best Practices

• Prefer a managed NOPASSWD sudoers drop-in in /etc/sudoers.d/ for the automation user so runs never depend on a typed or stored password. Scope it as tightly as your modules allow.
• If you must use a password, store ansible_become_password in Ansible Vault and unlock it with a vault_password_file, never plaintext in inventory.
• Keep become_method and become_user explicit in group_vars so a host never inherits the wrong escalation target.
• Validate sudo rights in CI with sudo -l against a sample host after image or sudoers changes, so a rebuilt node does not silently lose passwordless sudo.
• Remove Defaults requiretty from sudoers on hosts you automate; it breaks non-interactive escalation.
• For fast triage of escalation failures across a fleet, the free incident assistant can group Missing/Incorrect sudo password by host. See more in the Ansible guides.

Quick Command Reference

# Does the host just need a sudo password?
ansible <host> -i inventory.ini -b --ask-become-pass -m command -a 'id'

# What become config is in effect?
ansible-inventory -i inventory.ini --host <host> | grep -i become

# Show the user's sudo rights (look for NOPASSWD)
ansible <host> -i inventory.ini -b --ask-become-pass -m shell -a 'sudo -l'

# Test the password/method manually
ssh <user>@<ip> 'sudo -k; sudo -S whoami'

# Run with explicit prompts (password + vault)
ansible-playbook -i inventory.ini site.yml --ask-become-pass --ask-vault-pass

# Passwordless sudo drop-in (managed)
echo 'deploy ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/deploy

Conclusion

Missing sudo password and Incorrect sudo password are both become-layer failures. Missing means sudo wants a password you did not provide; Incorrect means the password (or become target) is wrong. The usual root causes:

1. The user has no NOPASSWD rule and no become password was supplied.
2. The supplied become password is wrong for the account.
3. become_user/become_method points at the wrong account (e.g. su needs root’s password).
4. A NOPASSWD sudoers rule exists but is scoped too narrowly.
5. The vaulted ansible_become_password did not load.
6. requiretty/lecture in sudoers breaks non-interactive escalation.

Confirm whether -K fixes it, inspect the become config, and check sudo -l on the host — that tells you whether to fix the credential, the become target, or the sudoers rule.