🚨 Ansible Error Guide: 'Incorrect sudo password' Privilege Escalation Failure

Exact Error Message

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

You may also see the closely related forms Incorrect su password, or in verbose output the underlying prompt mismatch:

Sorry, try again.
sudo: 3 incorrect password attempts

This is distinct from “Missing sudo password,” which means no password was supplied at all. Here a password was supplied, but sudo rejected it.

What the Error Means

When a task uses become: true with become_method: sudo, Ansible escalates privileges by running the remote command through sudo. If the remote sudoers configuration requires a password, Ansible feeds it the value of become_password (a.k.a. ansible_become_pass) and watches for sudo’s success or the “Sorry, try again” prompt.

Incorrect sudo password means Ansible did provide a password, but the one it supplied does not match what the remote sudo expects for the become user. The escalation attempt was actively rejected, not skipped.

Common Causes

• The wrong password is set in ansible_become_pass / --ask-become-pass (often a stale value after a rotation).
• The become password is confused with the SSH/login password; they may differ for the target user.
• A vaulted ansible_become_pass decrypts to the wrong value, or the wrong vault password was supplied.
• The become user is not who you think (become_user differs from the SSH user, and you supplied the SSH user’s password).
• Trailing whitespace or shell-quoting mangled the password in inventory or an environment variable.
• The account is locked or its password expired, so sudo rejects every attempt.

How to Reproduce the Error

Supply a deliberately wrong become password:

ansible web-01 -i inventory.ini -b -m ping --extra-vars "ansible_become_pass=wrongpass"

web-01 | FAILED! => {
    "changed": false,
    "msg": "Incorrect sudo password"
}

Or run a privileged playbook where inventory holds a stale ansible_become_pass:

ansible-playbook site.yml -i inventory.ini --check --diff -vvv

Diagnostic Commands

Run the failing escalation verbosely to confirm it is the password (not a prompt timeout):

ansible web-01 -i inventory.ini -b -m ping -vvv 2>&1 | grep -iE "sudo|become|password"

See exactly which become settings apply to the host:

ansible-inventory -i inventory.ini --host web-01

Reproduce with raw SSH and the same user to verify the password against real sudo:

ssh -v deploy@10.0.4.21 "sudo -k; echo 'YOURPASS' | sudo -S -p '' id"

Check whether the remote account is locked or expired (run with a known-good session):

ansible web-01 -i inventory.ini -b -m command -a "passwd -S deploy"

Step-by-Step Resolution

1. Confirm it is a wrong-password failure, not a missing one. Incorrect sudo password = supplied but rejected; Missing sudo password = none supplied. The fix differs.

2. Verify the password manually against real sudo for the exact user Ansible uses:

ssh deploy@10.0.4.21 "sudo -k; sudo -v"

If this also rejects the password, the problem is the credential/account, not Ansible.

3. Correct the become password. For interactive runs, prompt for it instead of trusting stale inventory:

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

4. Fix vaulted secrets. If ansible_become_pass comes from a vault, ensure you pass the right vault password and that the decrypted value is current:

ansible-vault view group_vars/web/vault.yml

5. Check you are escalating as the right user. Confirm become_user and that the password belongs to that account, not the SSH login user.

6. Rule out a locked/expired account. If passwd -S shows the account locked (L) or the password expired, fix the account on the host.

7. Re-test:

ansible web-01 -i inventory.ini -b -m ping --ask-become-pass

web-01 | SUCCESS => {"changed": false, "ping": "pong"}

Prevention and Best Practices

• Store become passwords in Ansible Vault, never in plaintext inventory, and rotate the vaulted value whenever the account password changes.
• Prefer passwordless sudo for automation accounts (a tightly scoped NOPASSWD sudoers entry) so there is no become password to get wrong.
• Keep ansible_user and become_user explicit so you always know whose password sudo expects.
• Quote and trim secrets carefully; a stray space or unescaped character produces a confusing “incorrect” rejection.
• After any password rotation, re-test escalation with ansible all -b -m ping to catch stale credentials before a real play.
• Monitor for locked/expired automation accounts; an expired password rejects every sudo attempt regardless of correctness.

Related Errors

• Missing sudo password — no password was supplied at all (use --ask-become-pass or set ansible_become_pass).
• Timeout (12s) waiting for privilege escalation prompt — sudo’s prompt never appeared, a different become problem.
• sudo: a password is required — sudoers requires a password Ansible did not provide.
• user is not in the sudoers file — an authorization problem, not a wrong password.

Frequently Asked Questions

What is the difference from “Missing sudo password”? “Missing” means Ansible supplied no password; “Incorrect” means it supplied one and sudo rejected it. For the latter, fix the value, not whether one is asked.

Is the become password the same as the SSH password? Not necessarily. become_user may be a different account with its own password. Make sure the password matches the user sudo is escalating to.

My vault decrypts fine but sudo still rejects it. The vaulted value may simply be stale after a rotation. Update the vaulted ansible_become_pass to the current password.

How do I avoid become passwords entirely? Grant the automation account passwordless sudo through a narrowly scoped NOPASSWD sudoers rule. For more become and SSH patterns, see the Ansible guides.