Ansible become: Fix Missing sudo Password & Privilege Escalation (Guide)

The Missing sudo password error occurs when Ansible needs to escalate privileges with become: true but doesn't have the sudo password. Here's every way to fix it.

The Error

fatal: [webserver1]: FAILED! => {"msg": "Missing sudo password"}

This happens when: become: true is set (Ansible tries to use sudo) The remote user requires a password for sudo No password was provided to Ansible

See also: Ansible Become: Privilege Escalation with sudo, su & runas (Complete Guide)

Fix 1: Passwordless Sudo (Recommended)

The cleanest solution — configure the remote user for passwordless sudo:

# On the remote host, add to /etc/sudoers.d/ansible
echo "ansible_user ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/ansible
sudo chmod 440 /etc/sudoers.d/ansible

Or automate it with Ansible (run once with --ask-become-pass):

- name: Configure passwordless sudo
  ansible.builtin.lineinfile:
    path: /etc/sudoers.d/ansible
    line: "{{ ansible_user }} ALL=(ALL) NOPASSWD: ALL"
    create: true
    validate: 'visudo -cf %s'
    mode: '0440'
  become: true

Fix 2: Command-Line Password Prompt

# Prompt for sudo password at runtime
ansible-playbook playbook.yml --ask-become-pass
# or shorthand
ansible-playbook playbook.yml -K

See also: Ansible Permission Denied (Errno 13): Fix File Access Errors

Fix 3: Inventory Variable

# inventory/hosts
[webservers]
web1 ansible_host=192.168.1.10 ansible_become_password=SecretPass123
[webservers:vars]
ansible_become_password=SharedSudoPass

⚠️ Security risk — passwords in plain text. Use Ansible Vault instead.

Fix 4: Ansible Vault (Recommended for Teams)

# Create encrypted variable file
ansible-vault create group_vars/webservers/vault.yml

# group_vars/webservers/vault.yml (encrypted)
ansible_become_password: "SecretPass123"

# Run with vault
ansible-playbook playbook.yml --ask-vault-pass
# or with vault password file
ansible-playbook playbook.yml --vault-password-file ~/.vault_pass

See also: Ansible Fix 'Missing sudo Password' Error: Become Configuration

Fix 5: Per-Task become_pass

- name: Restart critical service
  ansible.builtin.service:
    name: nginx
    state: restarted
  become: true
  vars:
    ansible_become_password: "{{ vault_sudo_password }}"

Fix 6: ansible.cfg Configuration

# ansible.cfg
[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = true

Diagnostic Steps

# Check if become is working
- name: Test privilege escalation
  ansible.builtin.command: whoami
  become: true
  register: whoami_result
- name: Show current user
  ansible.builtin.debug:
    msg: "Running as: {{ whoami_result.stdout }}"

# Test SSH + sudo manually
ssh user@remote "sudo -n whoami"
# If this returns "root", passwordless sudo works
# If it asks for password, you need one of the fixes above

Common Scenarios

AWS EC2 (Default: No Password Needed)

# ec2-user and ubuntu have passwordless sudo by default
[ec2]
web1 ansible_user=ec2-user ansible_ssh_private_key_file=~/.ssh/my-key.pem

Mixed Environment (Some Need Passwords)

[passwordless]
server1 ansible_user=ubuntu
[password_required]
server2 ansible_become_password="{{ vault_server2_pass }}"
server3 ansible_become_password="{{ vault_server3_pass }}"

Using su Instead of sudo

- name: Use su for privilege escalation
  ansible.builtin.service:
    name: httpd
    state: restarted
  become: true
  become_method: su
  become_user: root
  vars:
    ansible_become_password: "{{ vault_root_password }}"

Variable Precedence

Ansible checks for the sudo password in this order: ansible_become_password task variable ansible_become_password host variable ansible_become_password group variable --ask-become-pass / -K command-line prompt become_ask_pass in ansible.cfg

FAQ

What's the difference between ansible_become_password and ansible_sudo_pass?

ansible_sudo_pass is the old (deprecated) variable name. Use ansible_become_password instead — it works with all become methods (sudo, su, runas, etc.), not just sudo.

Is passwordless sudo a security risk?

It reduces one layer of defense, but for automation accounts it's the recommended approach. Mitigate by limiting which commands the user can run without a password, using SSH keys (not passwords) for login, and restricting the automation user's access.

Why does it work manually but fail in Ansible?

Common causes: SSH agent forwarding not passing through, different user context, or requiretty set in sudoers. Add Defaults:ansible_user !requiretty to your sudoers file.

Conclusion

The easiest fix is passwordless sudo for your Ansible user. For environments requiring passwords, use Ansible Vault to encrypt ansible_become_password. Never store sudo passwords in plain text inventory files.

Related Articles

• Ansible become: Privilege Escalation Guide • Ansible Vault Deep Dive • Ansible SSH Troubleshooting