🚨 Ansible Error Guide: 'Timeout (12s) waiting for privilege escalation prompt'

Overview

This error means Ansible escalated privileges (via sudo/su/etc.), then waited for the expected password prompt or success — and the timeout (default 12 seconds, timeout in [defaults]/ANSIBLE_TIMEOUT for the connection, become prompt handling internally) elapsed without the prompt Ansible was watching for. Either the prompt never appeared, appeared in unexpected text, or the escalation hung waiting on something (a password, PAM, a TTY).

You will see it on the first escalated task:

fatal: [web-01]: FAILED! => {"msg": "Timeout (12s) waiting for privilege escalation prompt: "}

The trailing text after the colon often shows what was received instead of the expected prompt. An empty tail means nothing came back at all (the escalation hung); a partial line like [sudo] password for deploy: means Ansible saw the prompt but the password it sent was wrong or sudo kept re-prompting.

Symptoms

• Tasks with become: true hang ~12s then fail with Timeout ... waiting for privilege escalation prompt.
• Increasing the timeout only delays the failure; it does not fix it.
• A manual sudo on the host either prompts unexpectedly or is slow.
• Works on most hosts; fails on a few with slow auth or odd sudoers.

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

web-01 | FAILED! => {
    "msg": "Timeout (12s) waiting for privilege escalation prompt: "
}

Common Root Causes

1. Wrong/missing become password — sudo keeps prompting

sudo asks for a password, Ansible sends the wrong one (or none), sudo re-prompts, and Ansible times out waiting for a success it never gets.

ansible web-01 -i inventory.ini -b --ask-become-pass -m command -a 'id' -vvv 2>&1 | grep -i password

[sudo] password for deploy:

If supplying the correct password with -K clears the timeout, the credential was the cause.

2. A localized or customized sudo prompt

Ansible matches a known prompt pattern. A non-English locale or a custom Defaults passprompt produces text Ansible does not recognize, so it waits past the timeout.

ansible web-01 -i inventory.ini -b --ask-become-pass -m shell -a 'grep -i passprompt /etc/sudoers /etc/sudoers.d/* 2>/dev/null; echo $LANG'

Defaults passprompt="Mot de passe: "
fr_FR.UTF-8

3. requiretty in sudoers

With Defaults requiretty, sudo refuses to run without a real terminal. Ansible’s non-interactive escalation then stalls or errors.

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

/etc/sudoers:Defaults    requiretty

4. Slow PAM / LDAP / sssd authentication

If sudo triggers a remote auth lookup (LDAP/AD via sssd) that is slow or timing out, the prompt/success takes longer than 12s.

ansible web-01 -i inventory.ini -b --ask-become-pass -m shell -a 'time sudo -k true' -vvv

real    0m14.2s

A sudo that itself takes >12s will always trip Ansible’s escalation timeout.

5. become_method needs a password Ansible is not configured to send

With become_method: su, the prompt is Password: and Ansible must send root’s password. If ansible_become_password is unset or for the wrong user, su waits and times out.

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

"ansible_become_method": "su"

6. A pre-task banner or MOTD interfering with the prompt parsing

A login banner or pam_motd output emitted at escalation time can be misread, delaying recognition of the prompt.

ansible web-01 -i inventory.ini -b --ask-become-pass -m shell -a 'ls /etc/update-motd.d/ 2>/dev/null; cat /etc/issue.net 2>/dev/null' -vvv

Diagnostic Workflow

Step 1: Confirm whether a correct password clears it

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

If -K with the right password succeeds, the cause is a missing/wrong become password.

Step 2: Time a raw sudo on the host

ansible web-01 -i inventory.ini -m shell -a 'time sudo -k -n true 2>&1 || echo needs-password' -vvv

A sudo that runs in well under 12s rules out slow auth; a slow one points at PAM/LDAP.

Step 3: Inspect sudoers for requiretty and custom prompts

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

requiretty or a custom passprompt explains why Ansible never sees the expected prompt.

Step 4: Check the become method and credentials

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

Ensure the password var matches the become_user/become_method actually in use.

Step 5: Apply the fix and, if auth is genuinely slow, raise the timeout

# remove requiretty / use NOPASSWD, or fix the credential, then:
ansible web-01 -i inventory.ini -b -m command -a 'id'

# only as a stopgap for legitimately slow auth:
ANSIBLE_TIMEOUT=30 ansible web-01 -i inventory.ini -b -m command -a 'id'

Example Root Cause Analysis

After joining a fleet to Active Directory via sssd, a handful of hosts begin failing escalation:

fatal: [app-09]: FAILED! => {"msg": "Timeout (12s) waiting for privilege escalation prompt: "}

Supplying the password with -K does not help, and most hosts are fine. Timing raw sudo on a failing host:

ansible app-09 -i inventory.ini -m shell -a 'time sudo -k -n true 2>&1 || echo needs-password'

real    0m17.5s
needs-password

sudo takes 17.5 seconds because its PAM stack consults sssd, and on app-09 the primary AD domain controller is unreachable, so every lookup waits for the LDAP timeout before falling back. Ansible’s 12-second escalation window expires first. The slow PAM/LDAP path — not the credential — is the root cause.

Fix: give the automation user passwordless sudo (which bypasses the slow PAM password lookup) and repair the sssd failover:

echo 'deploy ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/deploy
# and fix sssd ad_server / failover so PAM is fast again
ansible app-09 -i inventory.ini -b -m command -a 'id'

app-09 | CHANGED | rc=0 >>
uid=0(root) ...

Prevention Best Practices

• Use a managed NOPASSWD sudoers drop-in for the automation user. Passwordless sudo sidesteps prompt-parsing and slow PAM password lookups entirely.
• Remove Defaults requiretty from sudoers on automated hosts; it is the classic cause of stuck non-interactive escalation.
• Keep a consistent locale and avoid custom Defaults passprompt on hosts Ansible manages, so the prompt Ansible matches is the prompt it gets.
• Monitor sudo/PAM latency where sssd/LDAP is involved; a degraded directory makes every escalation slow. Fix failover rather than just raising ANSIBLE_TIMEOUT.
• Keep become_method/become_user and the matching password var explicit in group_vars so escalation never waits on a credential it was never given.
• For correlating escalation timeouts with a directory outage across many hosts, the free incident assistant can group the failures by cause. See more in the Ansible guides.

Quick Command Reference

# Does the correct password clear it?
ansible <host> -i inventory.ini -b --ask-become-pass -m command -a 'id'

# How long does sudo take on the host?
ansible <host> -i inventory.ini -m shell -a 'time sudo -k -n true 2>&1 || echo needs-password'

# Check sudoers for requiretty / custom prompt
ansible <host> -i inventory.ini -b --ask-become-pass -m shell \
  -a 'grep -Ei "requiretty|passprompt" /etc/sudoers /etc/sudoers.d/* 2>/dev/null'

# What become method/credentials are in effect?
ansible-inventory -i inventory.ini --host <host> | grep -i become

# Passwordless sudo drop-in (bypasses prompt + slow PAM)
echo 'deploy ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/deploy

# Stopgap for genuinely slow auth
ANSIBLE_TIMEOUT=30 ansible <host> -i inventory.ini -b -m command -a 'id'

Conclusion

Timeout (12s) waiting for privilege escalation prompt means Ansible escalated but never saw the prompt/success it expected within the window. The usual root causes:

1. A wrong/missing become password makes sudo re-prompt indefinitely.
2. A localized or custom sudo prompt that Ansible cannot match.
3. Defaults requiretty blocking non-interactive escalation.
4. Slow PAM/LDAP/sssd auth pushing sudo past 12 seconds.
5. become_method: su without the correct root password configured.
6. A login banner/MOTD interfering with prompt parsing.

Check whether the correct password clears it, time raw sudo, and inspect sudoers — the fix is almost always passwordless sudo, removing requiretty, or repairing slow directory auth, not merely increasing the timeout.