Timeout (XXs) waiting for privilege escalation prompt

Get Help
,
1

Hi!

Ansible is working fine on my servers, but on some machines, I get the following error when running superuser commands:

fatal: [143.129.78.26]: FAILED! => {
    "msg": "Timeout (32s) waiting for privilege escalation prompt: \u001b]11;?\u001b\\\u001b[6n\u001b[?25l\u001b[?2004h\r \u001b[D\u001b[2K\r"
}

All my machines are imaged using FOG, so they have the same OS. The machines that do not work are linked to another network adapter, but are part of the same subnet. A simple ping playbook works on all machines…

What could be the problem?

Cheers!

2

The ping module does not use privilege escalation.
So the problem is actually with privilege escalation.
Since you already found out what the common denominator is, that is where to look further.
The obvious thing to do is sign in manually and diagnose sudo (or whatever you use) on the affected hosts.

DIck

1 Like
3

Thanks for your reply!
From what I can see, there is no problem on these machines when using sudo manually, or through an ssh connection.

I can run the following command as well:

ssh root@143.129.78.26 shutdown -h now

The fact that the other machines that work have the exact same image makes me wonder if it is a networking issue, but then again, other ssh commands and playbooks still work…

4

What is your privilege escalation setup?
It defaults to sudo but it may be different in your case, for example something that relies on specific network connectivity.
I imagine something that does lookups in some sort of directory.

5

It should be set to sudo. There are no settings in the ansible config (other than a 30 second timeout).

I created a simple playbook that also fails:

---
- name: Test
  hosts: "143.129.78.26"
  become: yes
  tasks:
  - name: Testing
    shell: echo $USER
6

If you run that same simple playbook for both a working host and a failing one, with -vvvvv, and then compare the verbose logs?

1 Like
7

The ansible.cfg could be empty, but sudo could still be configured. Is it consistent, or triggered by something? If it’s consistent for certain hosts, check if any of the inventory variables are configuring ansible.builtin.sudo become – Substitute User DO — Ansible Community Documentation differently than the other hosts.

1 Like
8

Thank you for your replies!
Diffing both outputs made me realize that I accidentally put an ansible_user differently in the inventory.

Weird that this user is used as opposed to the default become_user; but my issue appears to be solved…

1 Like