Ansible: ERROR! Timeout (12s) waiting for privilege escalation prompt:

Exactly the same problem for me :worried:.

Ansible version : 2.0.0.2
Python Version : 2.7.6
Environment : Ubuntu 14.04

I have same problem with:
Ansible version : 2.0.0.2
Environment : Ubuntu 14.04

Same. Running into this during the very beginning at Setup Phase.
Ansible version : 2.0.0.2
Python Version : 2.7.6
Environment : Ubuntu 14.04

Just as a note, I switched the connection over to paramiko and the issue went away and the playbook ran fine. Seems to be an issue with the default OpenSSH implementation.

So for those who are having this issue, try using -c paramiko for now, until they fix this.

dupe of #14020

The error message is not the same as #14020 and the circumstances I describe here are a lot more broad. But if you say they are the same, I won't argue.

it is not exactly the same as this is on 'ssh' and the other using 'local' connection but i believe they are related to the rewritten 'prompt detection', still, will reopen this.

Could someone please post an excerpt of a playbook where the problem occurs (I understand it occurs unpredictably; I'm not asking for a way to reproduce it, just some context), as well as output of a failing run with ANSIBLE_DEBUG=y and -vvvvv?

I have the same problem with:
Ansible: 2.0.1.0-1ppa~precise
Ubuntu 12.04

# ansible 'web01' -m shell -a 'dmesg | tail -20' --become -vvvvv
Using /etc/ansible/ansible.cfg as config file
Loaded callback minimal of type stdout, v2.0
<web01> ESTABLISH SSH CONNECTION FOR USER: ansible
<web01> SSH: ansible.cfg set ssh_args: (-o)(ControlMaster=auto)(-o)(ControlPersist=60s)
<web01> SSH: ansible_password/ansible_ssh_pass not set: (-o)(KbdInteractiveAuthentication=no)(-o)(PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey)(-o)(PasswordAuthentication=no)
<web01> SSH: ANSIBLE_REMOTE_USER/remote_user/ansible_user/user/-u set: (-o)(User=ansible)
<web01> SSH: ANSIBLE_TIMEOUT/timeout set: (-o)(ConnectTimeout=10)
<web01> SSH: PlayContext set ssh_common_args: ()
<web01> SSH: PlayContext set ssh_extra_args: ()
<web01> SSH: found only ControlPersist; added ControlPath: (-o)(ControlPath=/home/user01/.ansible/cp/ansible-ssh-%h-%p-%r)
<web01> SSH: EXEC ssh -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=ansible -o ConnectTimeout=10 -o ControlPath=/home/user01/.ansible/cp/ansible-ssh-%h-%p-%r web01 '/bin/sh -c '"'"'sudo -H -S -n -u root /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-shpsnlhxruskuujwzskohueoshfyifah; /bin/sh -c '"'"'"'"'"'"'"'"'

web01 | FAILED | rc=0 >>
Timeout (12s) waiting for privilege escalation prompt:

Sometime it worked, but the most was FAILED.

@nghnam Could you please paste output of a failing run with ANSIBLE_DEBUG=1 set in the environment?

# ansible-playbook playbooks/test.yaml -vvvv  
TASK [setup] *******************************************************************
<my.ip.address.com> ESTABLISH SSH CONNECTION FOR USER: my_remote_user
<my.ip.address.com> SSH: EXEC ssh -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=/tmp/ansible-ssh-%h-%p-%r -o IdentitiesOnly=yes -o PasswordAuthentication=no -o StrictHostKeyChecking=no -o 'IdentityFile="/home/padraic/.ssh/my_totally_secure_identity_file"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=my_remote_user -o ConnectTimeout=10 my.ip.address.com '/bin/sh -c '"'"'sudo
 -i -u root /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-jpxmltbgxmgjairqscynmjxlxpgbtotc; /bin/sh -c '"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python'"'"'"
'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"''"'"'"'"'"'"'"'"''"'"''
fatal: [my.ip.address.com]: FAILED! => {"failed": true, "msg": "Timeout (12s) waiting for privilege escalation prompt: "}

Hey folks, similar error here on v2.0.1.0. -c paramiko suggested by @bbyhuy works every time but the @vutoff's disabling multiplexing suggestion in #13278 doesn't I'm afraid. Either way, I think one of these should be marked as a dupe of the other?

Here's a debug log of ANSIBLE_DEBUG=y ansible all -m ping -vvvvv where the problem occurs: https://gist.github.com/oliver/e5a24a5b37c0006bb220

This is with Ansible 2.0.1.0-1ppa~precise on Ubuntu 12.04, connecting to a Debian 8.2 VM running on the local host (so network problems are unlikely). I'm using become=True and become_method=su, and have added the root password in the hostsfile with ansible_sudo_pass='pass'. This setup worked fine with Ansible 1.9.4-1ppa~precise.

Not sure if this report should go at #14426 or #13278, but since this error doesn't seem to be related to with_items at all (it happens with any simple playbook and even with -m ping), I posted it here.

@oliver in your case it seems a mismatch on expected output, Passwort: is not getting matched with the su i18n prompt handler.

@bcoca Good catch (and a good argument against using i18n on a server)!
Unfortunately it still doesn't work if I set $LANG to an empty string and set the default locale on target system to None. I have updated the Gist and it now shows the "Password:" prompt which should be recognized but still leads to a timeout.

I believe the issues is on the 'su' prompt handling side (though it works for me in my tests).

Still having the same issue (2.0.1.0), msg is

FAILED! => {"failed": true, "msg": "Timeout (12s) waiting for privilege escalation prompt: "}

My play book Configuration

• hosts: dev-server
  
  become: yes
  
  become_user: root
  
  become_method: su
  
  *********************
  
  ouput of -vvvvv

ESTABLISH SSH CONNECTION FOR USER: ubuntu
SSH: ansible.cfg set ssh_args: (-o)(ControlMaster=auto)(-o)(ControlPersist=60s)
SSH: ANSIBLE_HOST_KEY_CHECKING/host_key_checking disabled: (-o)(StrictHostKeyChecking=no)
SSH: ansible_password/ansible_ssh_pass not set: (-o)(KbdInteractiveAuthentication=no)(-o)(PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey)(-o)(PasswordAuthentication=no)
SSH: ANSIBLE_REMOTE_USER/remote_user/ansible_user/user/-u set: (-o)(User=ubuntu)
SSH: ANSIBLE_TIMEOUT/timeout set: (-o)(ConnectTimeout=10)
SSH: PlayContext set ssh_common_args: ()
SSH: PlayContext set ssh_extra_args: ()
SSH: found only ControlPersist; added ControlPath: (-o)(ControlPath=/root/.ansible/cp/ansible-ssh-%h-%p-%r)
SSH: EXEC ssh -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=ubuntu -o ConnectTimeout=10 -o ControlPath=/root/.ansible/cp/ansible-ssh-%h-%p-%r -tt 52.76.16.117 '/bin/sh -c '"'"'( umask 22 && mkdir -p "echo $HOME/.ansible/tmp/ansible-tmp-1459250484.21-51977895368027" && echo "echo $HOME/.ansible/tmp/ansible-tmp-1459250484.21-51977895368027" )'"'"''
PUT /tmp/tmpMYXpV0 TO /home/ubuntu/.ansible/tmp/ansible-tmp-1459250484.21-51977895368027/setup
SSH: ansible.cfg set ssh_args: (-o)(ControlMaster=auto)(-o)(ControlPersist=60s)
SSH: ANSIBLE_HOST_KEY_CHECKING/host_key_checking disabled: (-o)(StrictHostKeyChecking=no)
SSH: ansible_password/ansible_ssh_pass not set: (-o)(KbdInteractiveAuthentication=no)(-o)(PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey)(-o)(PasswordAuthentication=no)
SSH: ANSIBLE_REMOTE_USER/remote_user/ansible_user/user/-u set: (-o)(User=ubuntu)
SSH: ANSIBLE_TIMEOUT/timeout set: (-o)(ConnectTimeout=10)
SSH: PlayContext set ssh_common_args: ()
SSH: PlayContext set sftp_extra_args: ()
SSH: found only ControlPersist; added ControlPath: (-o)(ControlPath=/root/.ansible/cp/ansible-ssh-%h-%p-%r)
SSH: EXEC sftp -b - -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=ubuntu -o ConnectTimeout=10 -o ControlPath=/root/.ansible/cp/ansible-ssh-%h-%p-%r '[machine1]'
ESTABLISH SSH CONNECTION FOR USER: ubuntu
SSH: ansible.cfg set ssh_args: (-o)(ControlMaster=auto)(-o)(ControlPersist=60s)
SSH: ANSIBLE_HOST_KEY_CHECKING/host_key_checking disabled: (-o)(StrictHostKeyChecking=no)
SSH: ansible_password/ansible_ssh_pass not set: (-o)(KbdInteractiveAuthentication=no)(-o)(PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey)(-o)(PasswordAuthentication=no)
SSH: ANSIBLE_REMOTE_USER/remote_user/ansible_user/user/-u set: (-o)(User=ubuntu)
SSH: ANSIBLE_TIMEOUT/timeout set: (-o)(ConnectTimeout=10)
SSH: PlayContext set ssh_common_args: ()
SSH: PlayContext set ssh_extra_args: ()
SSH: found only ControlPersist; added ControlPath: (-o)(ControlPath=/root/.ansible/cp/ansible-ssh-%h-%p-%r)
SSH: EXEC ssh -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=ubuntu -o ConnectTimeout=10 -o ControlPath=/root/.ansible/cp/ansible-ssh-%h-%p-%r -tt machine1 '/bin/sh -c '"'"'su root -c /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-lubjqfumkxawkkgetezusnctthxkfpju; /bin/sh -c '"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /home/ubuntu/.ansible/tmp/ansible-tmp-1459250484.21-51977895368027/setup; rm -rf "/home/ubuntu/.ansible/tmp/ansible-tmp-1459250484.21-51977895368027/" > /dev/null 2>&1'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"''"'"'"'"'"'"'"'"''"'"''

If i use sudo:yes , every thing working fine.

Running into this while running the setup phase against a freshly started Ubuntu 14.04 EC2 server.

When I run a second time the automation against the same server it works fine. It happens all the time when I first run an Ansible automation against a fresh server

Ansible version : 2.0.1.0
Python Version : 2.7.6
Environment : Ubuntu 14.04

I run the following command:

ANSIBLE_DEBUG=y ansible-playbook test.yaml -t configure -l <EC2_ID> -vvvvv

please see the following gist for the output: https://gist.github.com/Lowess/77442cf0533629e80b55faa7d6d91eb0

Can I at least increase that 12 sec timeout somehow?

The "12 sec timeout" is the timeout configuration setting + 2s (See ssh.py).

It's not a fix, but setting the timeout to 30 gave us a 32s escalation timeout which up to now was good enough (even for our slower AWS EC2 instances) to work around the bug.

@somechris I just tried your setting and it worked!

For some reason the setup phase takes around 20 - 25 secs. That is the first time I face this kind of issue while running Ansible against AWS. I still think there is an issue somewhere because with Ansible V1 I did not need to increase that timeout value.

Thanks again!

I suspect the timeout just didn't work as intended in v1.

@amenonsen In that case all make sense to me now. Thanks for the precision.

Same issue.

Ansible Host: Ubuntu 14.04
Managed Hosts: CentOS 7.2

Workaround described here has helped

pre_tasks:
  - name: disable fingerprint checking that may be enabled; when enabled, causes ssh issues
    command: authconfig --disablefingerprint --update
    become: yes

Symptoms were exactly the same (here is the syslog from centos hosts)

Apr  7 22:44:12 srv-01 python: ansible-file Invoked with directory_mode=None force=False remote_src=None path=/etc/connector owner=connector follow=False group=connector state=directory content=NOT_LOGGING_PARAMETER serole=None diff_peek=None setype=None selevel=None original_basename=None regexp=None validate=None src=None seuser=None recurse=False delimiter=None mode=None backup=None 
Apr  7 22:44:13 srv-01 dbus[703]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
Apr  7 22:44:13 srv-01 dbus-daemon: dbus[703]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
Apr  7 22:44:13 srv-01 systemd: start request repeated too quickly for fprintd.service
Apr  7 22:44:13 srv-01 systemd: Failed to start Fingerprint Authentication Daemon.
Apr  7 22:44:13 srv-01 systemd: fprintd.service failed.
Apr  7 22:44:38 srv-01 dbus[703]: [system] Failed to activate service 'net.reactivated.Fprint': timed out
Apr  7 22:44:38 srv-01 dbus-daemon: dbus[703]: [system] Failed to activate service 'net.reactivated.Fprint': timed out

@szhem awesome, that fixed it for me!

authconfig --disablefingerprint --update

Is there an equivalent command on ubnutu 14.04? Happening to us as well

In ansible.cfg set transport=paramiko in the [defaults] section

In ansible.cfg, the following has fixed the issue for 10+ server deploys using ansible 2.0.1.0:

[defaults]
timeout = 30

Paramiko does not seem to work with my bastion configuration, while ssh works like a charm (minus become/become_user/become_method: su). I'm being bit by this bug hard, are there any details I can provide to help?

<vagrant.dev> PUT /var/folders/br/p6m9m2ks0v9868lpyphsxdfr0000gp/T/tmpqcF4PG TO /home/vagrant/.ansible/tmp/ansible-tmp-1466186263.1-239875858441470/setup <vagrant.dev> SSH: EXEC sshpass -d25 sftp -b - -C -vvv -C -o ControlMaster=auto -o ControlPersist=60s -o Port=22 -o User=vagrant -o ConnectTimeout=15 -o ControlPath=/Users/vagrant/.ansible/cp/ansible-ssh-%h-%p-%r '[vagrant.dev]' fatal: [vagrant.dev]: UNREACHABLE! => {"changed": false, "msg": "ERROR! SSH Error: data could not be sent to the remote host. Make sure this host can be reached over ssh", "unreachable": true}

I too wonder if setup is just slower in 2.x. We see setup timeouts very often when running against 2.1, but never with 1.9. We have increased the timeout to 30, but still it happens quite often on 2.1. (Will increase more to try to see if this is really a timeout or something that will never completed.)

FYI we haven't seen that error in a couple of months. We implemented the workaround from @szhem for our RHEL 6.7 hosts and that apparently fixed it. For our RHEL 7.2 hosts, they use a newer version of authconfig (version 6.2.8-10) which apparently fixes that problem, because for them we don't need the workaround.

We are using RHEL 7.2 on our Jenkins slaves and Tower servers as well.

Running 2.2 from source with CentOS 7.2 hosts from Azure.

Strangely some systemd service calls ends up into Timout (12s).

I got rid of this error by adding nopasswd to my user in /etc/sudoers
username ALL=(ALL) NOPASSWD:ALL

should be at the end of sudoers

@gandhar I've encountered this error while already having the nopasswd on. Looks like it's just one of many things that consume the timeout.

Did you try debug your ssh server at nodes? How much time take ssh login to node? Try to add UseDNS no to /etc/ssh/sshd_config file on the nodes.

• 1
  The problem happens when i deploy more than 3 AWS EC2 at the same time.
  @somechris thanks for the work around, it works fine even in strategy: free mode.

FAILED! => {"failed": true, "msg": "Timeout (12s) waiting for privilege escalation prompt: "
OS : CentOS Linux release 7.2.1511 (Core)
Ansible: ansible 2.2.0

For the record. I see the problem with FreeBSD PF firewall. SSH port is open and SSH connection from a commandline works fine. The timeout disappears when I disable the firewall.

WORKAROUND

./lib/ansible/plugins/connection/ssh.py line 403 (commit 9fe430867063a0a63316e9bb71e9ba03a475a989):

from:

timeout = 2 + self._play_context.timeout

to:

timeout = 30 + self._play_context.timeout

ROOT CAUSE

Laggy environments (public clouds etc) can cause timeouts due strict default timeout. User should be able to configure the timeout to fit their needs but context.timeout is not updating when editing ansible.cfg.

folding into #13278

same problem, adding become_user: <username>
removed the error

Faced with similar problem ,Adding -c paramiko to my ansible-play command helped to resolve this issue.

I'm running ansible 2.1.1.0 and I was getting this error. The only way I got it to work was with the following in my playbook:

remote_user: david
sudo: yes

And adding the --ask-become-pass to the command.

Newbie here, was having this problem. Fixed with:

sudo:yes

Which replaced:

become: yes
become_user: root
become_method: su

I'm fairly certain it's my own user error somehow but for now I'm using the deprecated method.

Version 2.0.0.2

Turns out I was using the wrong become_method (su), this works by using default (sudo):

become: yes

I always get this error when I kill ansible (ctrl+c) and try to restart the play again. Adding -c paramiko solves the problem here too. After a while it will resume working normally, so I guess that something needs to time out on the server...
However, this may be a different issue, because it always happens at the very beginning of the play, and never at random times during the play.

Honestly, what even was the point of changing this? In the course of what looks like 2 minor revisions pretty much all of my playbooks are currently broken. Other than converting all of this become behavior, ansible worked flawlessly.

https://github.com/ansible/ansible/issues/14426#issuecomment-205938301 from @somechris suggests that timeout affects escalation timeouts. However the documentation linked clearly states:

This is the default SSH timeout to use on connection attempts:

If people are reporting that increasing the timeout is causing the escalation prompt errors to go away, it would seem that the documentation is broken, or there is another more sinister problem buried somewhere in there.

@tsoikkel made an analysis of the actual code here:
https://github.com/ansible/ansible/issues/14426#issuecomment-245256330

Which suggests that the documentation is correct, but does not suggest why changing the timeout fixes the escalation problem.

The commit referenced link doesn't actually show the relevant code, but here it is in the current master:

https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/connection/ssh.py#L418-L421

Is the escalation problem an SSH timeout, or a command execution timeout, or something else? It's not clear from this discussion what the real root cause is.

Here's the specific code as it relates to escalation prompt errors:

https://github.com/ansible/ansible/blob/ac51266e8fea1ac6312a9649fc5cf10dd0609925/lib/ansible/plugins/connection/ssh.py#L438-L445

Unfortunately I'm not enough of a python person to be able to discern when this would happen. Perhaps someone can explain the flow here, as I'm not sure why reaching the timeout value in this particular instance would cause the error to be raised.

By increasing the timeout we are hiding the real reason why ssh failed on a first place with 12s retry value which is still significant.

is anyone aware why ansible fails to connect to the host so randomly? for example, we have 50 nodes in our setup managed by ansible and time out happen 3% of time on totally random nodes and random tasks and if we re-ran the playbook for the second time it would be fine.

Hi,
sorry for commenting to closed ticket.
We experienced the same problem with ansible 2.2.0 and 2.2.2 and we managed the problem appears only with Python 3.5. In Python 2.7 it all seems to be ok.

still have the issue with it

I have this issue. Why issue is closed?

I too am seeing this. This isn't fixed and shouldn't be closed.

Seeing this in latest ansible. Why is this closed?

I'm also seeing this in 2.3.0

Please comment on the issue above your comment. The mods will respond that this is closed.

I needed to remove the -n flag, which was causing an issue with sudo'ing with no password.
Once I did that, this error then started to occur.
Per @davidmoshal 's comment, I changed become: yes to become: root and my issue went away.

become: root is incorrect, it does not set the user, but it ends up being a True value for become so it is really no change.

I can confirm that rolling back to ansible1.9 resolves all of my weird SSH connection issues. I don't know what is wrong with ansible2.x but I will not be upgrading any time soon since this seems to continue to persist. I've seen comments that this is not an ansible bug, and I firmly disagree. The only variable I've changed is an ansible upgrade. I manage over 70 servers with no issues with ansible1.9, ansible 2.0 fails with every instance I have. This is an ansible bug. Not ssh, or any other layer.

Just had this problem for me it was happening 4-5 times in a row. Ansible 2.3, Ubuntu 16.04.1.
But as I have not had any issues today in the area where it started happening and I did not do any changes there I just started to think that something goes wrong with the controlling node itself.
I decided to restart controlling node and try again and it worked for me with no issues. The problem gone.

Also have this same issue with 2.3.0.0 and 2.4.1.0 with pipelining. Due to a mis-configuration on our end, pipelining had been disabled by accident for a while now (not sure how long, I suspect pre-2.0 switch), but enabling it again resulted in the privilege escalation prompt timeout mentioned here.

I use simply become = True and become_method = sudo. The only 'special' thing really I do is set the ANSIBLE_SSH_ARGS so it writes it's UserKnownHostsFile to a specific custom location - but I doubt this would affect anything?

I've tried switching to paramiko, but that crashed & burned completely in my test setup and increasing the timeouts also didn't work, it failed both in my test-setup as on our production environment.

Setup:

• Ansible 2.4.0 Ubuntu 16.04 control machine VirtualBox 5.1.30 VM (Vagrantbox: bento/ubuntu-16.04)
• Solaris 11.3 VirtualBox 5.1.30 VM (Vagrantbox: heavybeans/solaris11-small-server)

Randomly get this error when testing a playbook, last time it was during a file action (the folder already existed). The two VMs have the same user "vagrant" and the Solaris box has no root password.

I used --ask-become-pass and pressed ENTER. Still, the error happened...

In my case, it was a real problem (not a bug) on my server where DNS would not resolve. sudo apparently uses DNS to resolve the hostname of the machine, and if this fails, it will timeout. I fixed it by correcting the DNS entry in my /etc/resolv.conf.

Having this problem often in GCE with Ansible 2.5 from git as well. So far using paramiko seems to be a viable workaround.

I had to killall ssh, maybe a stale ssh connection if you are using ControlPersist.

Hi, i have the same trouble with deploying to ubuntu 16.04 with ansible 2.4.2.0, the --paramiko option solve the problem, but in same case dont read my ~/.ssh/config, so instead of --paramiko option I solve disabling the option pipelining (by default is False) in the ansible.cfg add:

[ssh_connection]
pipelining = False

I experienced the same issue when trying to run a playbook on a LXD Ubuntu 16.04 container. I could ssh into the container just fine, but it would take a long time to sudo su and it would error sudo: unable to resolve host ingest0: Connection timed out.

I added the hostname to /etc/hosts and the problem went away - I could run the playbook without it timing out on escalation and I could sudo su immediately.

root@ingest0:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 ingest0

I'm using ansible 2.4.3.0 and python 2.7.12.

my issue was resolved by changing the hosts file from

[sandbox]
fedora@ip

to

[sandbox]
ip

where ip is the ip address of the machine.

Why is this closed?
I have just set up a brand new Ubuntu server with latest Ansible and Python and the bug is still there.
None of the workarounds work.

Why is this closed?

Probably because it isn't possible to ask every user if the solution(s) work. Incidentally there are probably multiple different causes of the error. The person made a judgment call to close the issue.

I agree,

I am having the same issue, I have given the user sudoers root.... I have forced change of users.

Nothing works and reasonable error to investigate. Maybe better exception handling is required here?

My playbook looks like this:

• hosts: localhost

become_user: jenkins
gather_facts: true
roles:
- { role: bareos, tags: local}

• hosts: dev-cluster
  remote_user: centos
  gather_facts: true
  roles:

  • { role: bareos, tags: client}

• hosts: backup
  remote_user: centos
  become_user: root
  gather_facts: true
  roles:

  • { role: bareos, tags: server}

All other hosts work but the hosts: backup.

-vvv Shows

Using module file /usr/lib/python2.7/site-packages/ansible/modules/system/setup.py
ESTABLISH SSH CONNECTION FOR USER: centos
SSH: EXEC ssh -o ControlMaster=auto -o ControlPersist=30m -o ConnectionAttempts=100 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o 'IdentityFile="/var/jenkins_home/.ssh/demo.pem"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=centos -o ConnectTimeout=10 -o ControlPath=/var/jenkins_home/.ansible/cp/cd7d91cc23 backup.infra.com '/bin/sh -c '"'"'sudo -H -S -n -u root /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-uywjmsrvdxhojzxfiqjygdwdsmbvvfzn; /usr/bin/python'"'"'"'"'"'"'"'"' && sleep 0'"'"''

Sever is in AWS.
I have in my ansible command

ansible-playbook -vvv -i inventory/hosts bareos.yml --key-file "~/.ssh/demo.pem" -b -e

i just have this problem，this accur become user and model copy . however when i use root direct run playbook that's ok.

error msg :

SSH: EXEC sshpass -d13 ssh -C -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o User=vmuser -o ConnectTimeout=20 -o ControlPath=/root/.ansible/cp/48d4a08c2f -tt 192.168.202.105 '/bin/sh -c '"'"'su root -c '"'"'"'"'"'"'"'"'/bin/sh -c '"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-fkekucjxphrobughycoiecflsoiptmkg; /usr/bin/python /home/vmuser/.ansible/tmp/ansible-tmp-1536311364.58-186480404230053/file.py'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"'"''"'"'"'"'"'"'"'"' && sleep 0'"'"''
fatal: [192.168.202.105]: FAILED! => {
"msg": "Timeout (22s) waiting for privilege escalation prompt: "

I agree,

I am having the same issue, I have given the user sudoers root.... I have forced change of users.

Nothing works and reasonable error to investigate. Maybe better exception handling is required here?

My playbook looks like this:

• hosts: localhost

become_user: jenkins
gather_facts: true
roles:

• { role: bareos, tags: local}

• hosts: dev-cluster
  remote_user: centos
  gather_facts: true
  roles:

  • { role: bareos, tags: client}

• hosts: backup
  remote_user: centos
  become_user: root
  gather_facts: true
  roles:

  • { role: bareos, tags: server}

All other hosts work but the hosts: backup.

-vvv Shows

Using module file /usr/lib/python2.7/site-packages/ansible/modules/system/setup.py
ESTABLISH SSH CONNECTION FOR USER: centos
SSH: EXEC ssh -o ControlMaster=auto -o ControlPersist=30m -o ConnectionAttempts=100 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o 'IdentityFile="/var/jenkins_home/.ssh/demo.pem"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=centos -o ConnectTimeout=10 -o ControlPath=/var/jenkins_home/.ansible/cp/cd7d91cc23 backup.infra.com '/bin/sh -c '"'"'sudo -H -S -n -u root /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-uywjmsrvdxhojzxfiqjygdwdsmbvvfzn; /usr/bin/python'"'"'"'"'"'"'"'"' && sleep 0'"'"''

Sever is in AWS.
I have in my ansible command

ansible-playbook -vvv -i inventory/hosts bareos.yml --key-file "~/.ssh/demo.pem" -b -e

>

My issue was firewall related. For me this is resolved.

For me, it was because of the bad internet connection.

I'm getting this issue as well:
Playbook:

- name: Configure cassandra.yaml common settings
  become: yes
  become_user: cassandra
  become_method: su
  become_flags: '-s /bin/sh'
  lineinfile:
    path: /usr/local/cassandra/conf/cassandra.yaml
    regexp: '{{ item.beginning }}'
    line: '{{ item.beginning }}{{ item.value }}{{ item.end }}'
  with_items: "{{ cassandra_yaml }}"

Which gives the error:

TASK [install-cassandra : Configure cassandra.yaml common settings] *************************************************
fatal: [10.142.0.3]: FAILED! => {"msg": "Timeout (32s) waiting for privilege escalation prompt: "}

The playbook has lots of other tasks which get done without issues. Just this one with the different "become" options, fails.

My 3 cents:
Similar issue here. Same error. I had no time to debug but what I spotted:

1) This is network related (my connection is via HE6 tunnel to Ubunut 18.04->LXD containter). With one tunnel setup same error as above. With other tunnel setup works ok (I'm guessing here but this is propably MTU issue of some kind).

1. ANSIBLE_SSH_ARGS="-o ControlMaster=no" helps a little - connection stuck on diffrent task when used.