Ansible Privilege Escalation Errors: Troubleshoot become & sudo

Today we're going to talk about Ansible troubleshooting and specifically about privilege escalation errors. I'm Luca Berton and welcome to today's episode of Ansible Pilot. It happens when the connection user Ansible doesn't have the permission to perform the operation. The solution is simply to switch to the user with administrative rights. In Ansible you perform this operation enabling the become statement. Behind the scenes Ansible is connecting to the target host using the normal user, switching to the administrative user and then executing the playbook code. The standard privilege escalation method is sudo but more are available for example su, pfexec, doas, pbrun, dzdo, ksu, runas, machinectl, Centrify, etc.

Links

• Understanding privilege escalation: become

## Playbook The best way of talking about Ansible troubleshooting is to jump in a live Playbook to show you practically the privilege escalation error and how to solve it!

error

---
- name: yum module Playbook
  hosts: all
  become: false
  tasks:
    - name: install package
      yum:
        name: git
        state: present

fix

---
- name: yum module Playbook
  hosts: all
  become: true
  tasks:
    - name: install package
      yum:
        name: git
        state: present

Now you know better how to troubleshoot the most common Ansible error about privilege escalation.

See also: Ansible 'This command has to be run under the root user' Error: Fix with become

Understanding Ansible Privilege Escalation

By default, Ansible connects to managed hosts as a regular user. Many tasks (installing packages, modifying system files, managing services) require root or administrative privileges. Ansible's become feature handles this.

How become Works

Ansible connects via SSH as remote_user If become: true, it escalates privileges using become_method (default: sudo) It switches to become_user (default: root) The task executes with elevated privileges

Common Privilege Escalation Errors

Error 1: Missing sudo password

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

Fix — provide the password:

# Interactive prompt
ansible-playbook playbook.yml --ask-become-pass
# Or use -K shorthand
ansible-playbook playbook.yml -K

Fix — passwordless sudo (recommended for automation):

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

Error 2: User is not in the sudoers file

fatal: [server]: FAILED! => {"msg": "devops is not in the sudoers file. This incident will be reported."}

Fix:

# As root on the target host
usermod -aG wheel devops   # RHEL/CentOS/Fedora
usermod -aG sudo devops    # Ubuntu/Debian

Error 3: Sorry, try again (wrong password)

fatal: [server]: FAILED! => {"msg": "Incorrect sudo password"}

Fix: Verify the password is correct. If using Ansible Vault:

# group_vars/all/vault.yml (encrypted)
ansible_become_password: "{{ vault_sudo_password }}"

ansible-playbook playbook.yml --ask-vault-pass

Error 4: sudo: a terminal is required

fatal: [server]: FAILED! => {"msg": "sudo: a terminal is required to read the password"}

Fix: The requiretty option in sudoers is blocking Ansible. Disable it:

# On the target host
echo "Defaults !requiretty" | sudo tee /etc/sudoers.d/disable-requiretty

Or enable pipelining in Ansible:

# ansible.cfg
[ssh_connection]
pipelining = True

See also: Ansible PowerShell & sudo Become Error: 'powershell is not compatible' Fix

Playbook Examples

Basic privilege escalation

---
- name: Install packages with become
  hosts: all
  become: true
  become_method: sudo
  become_user: root
  tasks:
    - name: Install nginx
      ansible.builtin.package:
        name: nginx
        state: present

Per-task escalation

---
- name: Mixed privilege playbook
  hosts: all
  tasks:
    - name: Check disk space (no sudo needed)
      ansible.builtin.command: df -h
      register: disk_output
- name: Install package (needs sudo)
      ansible.builtin.apt:
        name: htop
        state: present
      become: true

Switch to a specific user

---
- name: Run as postgres user
  hosts: db_servers
  tasks:
    - name: Create database
      community.postgresql.postgresql_db:
        name: myapp
      become: true
      become_user: postgres
      become_method: sudo

Available become Methods

| Method | Description | Use Case | |--------|-------------|----------| | sudo | Default, most common | Linux/macOS | | su | Switch user | When sudo isn't available | | pbrun | PowerBroker | Enterprise environments | | pfexec | Profile-based exec | Solaris | | doas | OpenBSD sudo alternative | BSD systems | | runas | Windows escalation | Windows targets | | machinectl | systemd container exec | systemd-nspawn |

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

FAQ

Should I use become: true at play level or task level?

Use play level when most tasks need root. Use task level when only some tasks need elevation. Task-level is more secure (principle of least privilege).

How do I pass the become password securely?

Use Ansible Vault to encrypt the password:

ansible-vault encrypt_string 'mysecretpassword' --name 'ansible_become_password'

Why does become fail with su method?

The su method requires the target user's password (usually root), not the connecting user's password. Make sure you're providing the right password with --ask-become-pass.

Common Errors and Fixes

"Missing sudo password"

# Fix 1: Provide become password
ansible-playbook site.yml -K  # --ask-become-pass
# Fix 2: In inventory
ansible_become_password: "{{ vault_sudo_pass }}"
# Fix 3: Passwordless sudo on remote
# /etc/sudoers.d/deploy
# deploy ALL=(ALL) NOPASSWD: ALL

"sudo: a terminal is required"

# Fix: Enable pipelining OR disable requiretty
# ansible.cfg
[ssh_connection]
pipelining = true

# Or fix on remote host
- lineinfile:
    path: /etc/sudoers
    regexp: '^Defaults.*requiretty'
    state: absent
    validate: 'visudo -cf %s'
  become: true

"Permission denied" with become

# Check become settings
- hosts: all
  become: true
  become_user: root
  become_method: sudo  # Explicit method
  tasks:
    - command: whoami
      register: who
    - debug: var=who.stdout

"User not in sudoers file"

# Add user to sudoers
- name: Grant sudo access
  ansible.builtin.copy:
    content: "deploy ALL=(ALL) NOPASSWD: ALL\n"
    dest: /etc/sudoers.d/deploy
    mode: '0440'
    validate: 'visudo -cf %s'
  become: true  # Need existing sudo to fix this

Become to Non-Root User

# May fail without proper sudo config
- command: /opt/myapp/start.sh
  become: true
  become_user: appuser
# Fix: Allow deploy to become appuser
# /etc/sudoers.d/deploy
# deploy ALL=(appuser) NOPASSWD: ALL

Debugging

# Verbose output shows become commands
ansible web1 -m command -a "whoami" --become -vvvv
# Test manually
ssh deploy@web1
sudo -u root whoami
sudo -u appuser whoami

Become Methods

# sudo (default)
become_method: sudo
# su (requires root password)
become_method: su
# doas (OpenBSD)
become_method: doas
# pfexec (Solaris)
become_method: pfexec
# runas (Windows)
become_method: runas
become_user: Administrator

Sudoers Configuration

- name: Configure secure sudoers
  ansible.builtin.copy:
    content: |
      # Ansible managed - do not edit
      deploy ALL=(ALL) NOPASSWD: ALL
      appuser ALL=(ALL) NOPASSWD: /opt/myapp/restart.sh
    dest: /etc/sudoers.d/ansible
    mode: '0440'
    validate: 'visudo -cf %s'
  become: true

Common Patterns

| Error | Likely Cause | Fix | |-------|-------------|-----| | Missing sudo password | No NOPASSWD in sudoers | Add -K flag or configure sudoers | | requiretty | Old sudoers config | Enable pipelining or remove requiretty | | Not in sudoers | User lacks sudo access | Add to sudoers.d | | Permission denied | Wrong become_user | Check sudoers allows target user | | Module failure | become not set | Add become: true |

FAQ

Can I use different sudo passwords per host?

Yes — set ansible_become_password in host_vars/:

# host_vars/legacy.yml
ansible_become_password: "{{ vault_legacy_sudo }}"

How do I become without sudo?

Use become_method: su (needs root password) or configure polkit/doas as alternatives.

Why does my task fail even with become?

The become user might lack permissions for that specific action. Check file ownership, service permissions, and SELinux context.

Common Errors

"Missing sudo password"

# Fix 1: Prompt for password
ansible-playbook site.yml -K
# Fix 2: Passwordless sudo on remote
echo "deploy ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/deploy
# Fix 3: Set in inventory
ansible_become_password: "{{ vault_sudo_pass }}"

"sudo: a terminal is required"

# /etc/sudoers — remove requiretty
# Comment out: Defaults requiretty
# Or in ansible.cfg:
[ssh_connection]
pipelining = False  # Disable if requiretty can't be changed

"sudo: sorry, you must have a tty"

Same fix as above — remove requiretty from sudoers or disable pipelining.

"Permission denied"

# Check: is become enabled?
- hosts: all
  become: true          # Must be true
  become_user: root     # Default
  become_method: sudo   # Default

become Configuration

# Playbook level
- hosts: all
  become: true
  become_method: sudo
  become_user: root
# Task level
- command: /opt/admin-tool
  become: true
  become_user: appuser
# ansible.cfg
# [privilege_escalation]
# become = True
# become_method = sudo

Alternative become Methods

# su (switch user)
become_method: su
ansible_become_password: "{{ root_password }}"
# pbrun (PowerBroker)
become_method: pbrun
# doas (OpenBSD)
become_method: doas
# runas (Windows)
become_method: runas
ansible_become_password: "{{ admin_password }}"

Become a Non-Root User

- copy:
    src: config.yml
    dest: /opt/myapp/config.yml
  become: true
  become_user: appuser  # Run as appuser, not root

Debug Privilege Escalation

# Verbose output shows become commands
ansible web1 -m command -a "whoami" -b -vvv
# Check sudo config on remote
ansible web1 -m command -a "sudo -l"
# Test without Ansible
ssh deploy@web1 'sudo -n whoami'

Sudoers Best Practices

# Limit to specific commands (more secure)
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl, /usr/bin/apt, /usr/bin/yum
# Allow specific become_user
deploy ALL=(appuser) NOPASSWD: ALL

FAQ

become: true vs become: yes?

Both work — YAML treats true/yes as boolean true. true is preferred by ansible-lint.

Can I escalate on some tasks only?

Yes — set become: true per-task instead of per-play. Better security practice.

"Incorrect sudo password" but password is right?

Check: locale issues (special characters in password), password for wrong user (might need root's password with su), PAM configuration blocking.

Related Articles

• the Ansible become reference • the Ansible roles overview