Fix Ansible "Timeout (12s) waiting for privilege escalation prompt" with become

The Error

You run a playbook with become: true and Ansible just… hangs. Twelve seconds later:

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

Or the shorter variant:

Timeout (12s) waiting for privilege escalation prompt

The play stops dead. SSH works fine. No task ever runs.

What's Actually Happening

become: true tells Ansible to escalate privileges on the remote host — usually via sudo. When sudo is configured to require a password and Ansible doesn't supply one, it stares at the password prompt until the 12-second clock runs out.

Six different things can trigger this. The fix depends on which one you're hitting.

Root Causes (and Fixes)

1. No become password provided (most common)

The remote user's sudo requires a password, but Ansible has no idea what it is.

Quick fix — prompt for it at runtime:

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

Ansible asks once, then reuses that password across all hosts in the run.

Better fix — store it in group_vars:

# inventory/group_vars/all.yml
ansible_become_password: "your_sudo_password_here"

Never commit plaintext passwords. Encrypt the file with Ansible Vault:

ansible-vault encrypt inventory/group_vars/all.yml

Then run with:

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

2. Passwordless sudo not configured on the remote host

For automation, you usually want sudo without a password. Add a dedicated sudoers file on each managed host — don't edit /etc/sudoers directly:

sudo visudo -f /etc/sudoers.d/ansible

Add this line, replacing deploy with your actual Ansible user:

deploy ALL=(ALL) NOPASSWD: ALL

Need tighter control? Scope it to specific binaries:

deploy ALL=(ALL) NOPASSWD: /usr/bin/apt, /bin/systemctl

Verify it works before touching Ansible at all:

ssh deploy@web01 sudo whoami

If that prints root with no password prompt, Ansible will work too.

3. sudo requires a TTY (requiretty in sudoers)

Older RHEL/CentOS releases ship with Defaults requiretty in /etc/sudoers. Ansible doesn't allocate a TTY by default, so sudo flat-out refuses.

Confirm this is the issue:

ssh deploy@web01 "sudo -n whoami" 2>&1

You'll see: sudo: sorry, you must have a tty to run sudo. That's your culprit.

Fix A — disable requiretty for the Ansible user only:

Defaults:deploy !requiretty

Fix B — tell Ansible to allocate a pseudo-TTY:

# per-play
- hosts: all
  become: true
  vars:
    ansible_ssh_extra_args: '-tt'

One hard constraint: -tt and pipelining = true cannot coexist. Pick one.

4. Pipelining enabled but become password needed

pipelining = true speeds up playbook execution by 30–50% on large inventories, but it kills interactive password prompts. The two features are fundamentally incompatible.

# ansible.cfg
[ssh_connection]
pipelining = true  # ← blocks interactive become passwords

Your options: disable pipelining, or configure passwordless sudo so Ansible never prompts in the first place. The second option is almost always better.

5. Wrong become_method

Ansible defaults to sudo. If the host uses su, doas, or pbrun, Ansible sends the wrong escalation command — and the prompt never matches what it expects.

# playbook
- hosts: bsd_servers
  become: true
  become_method: doas   # match whatever the host actually uses

Or set it globally:

[privilege_escalation]
become_method = su

6. Timeout too short for slow hosts

Under heavy load — think a host pegged at 90% CPU, or a cross-continent SSH hop — sudo can take longer than 12 seconds to respond. Bump the timeout:

# ansible.cfg
[defaults]
timeout = 30

[privilege_escalation]
become_timeout = 30

Per-play override:

- hosts: all
  become: true
  vars:
    ansible_timeout: 30

Verification

After any fix, this one-liner is the fastest sanity check:

ansible web01 -i inventory -m command -a "whoami" --become

Expected output:

web01 | CHANGED | rc=0 >>
root

Still timing out? Add -vvvv and grep for where it stalls:

ansible-playbook site.yml -i inventory --become -vvvv 2>&1 | grep -A5 "privilege"

Recommended ansible.cfg Setup

This config sidesteps most of the causes above. Pair it with passwordless sudo on the remote host and you're done:

[defaults]
timeout = 30
host_key_checking = false

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false

[ssh_connection]
pipelining = true
# Disable pipelining only if you need interactive become passwords

Prevention

• Set up passwordless sudo for your Ansible service account when you provision a host — retrofitting it later is friction you don't need.
• Store become passwords in Ansible Vault. Plaintext credentials in inventory files have a way of ending up in git history.
• Run ssh deploy@host sudo whoami manually before executing playbooks against new hosts. Catching sudo issues outside Ansible makes them much easier to debug.
• If your team shares ansible.cfg, add a comment explaining whether pipelining is on and why — mixing pipelining with password-based become trips people up on every project that doesn't document it.