Ansible: ¡ERROR! Tiempo de espera (12 s) esperando la solicitud de escalamiento de privilegios:

Exactamente el mismo problema para mí: preocupado :

Versión de Ansible: 2.0.0.2
Versión de Python: 2.7.6
Entorno: Ubuntu 14.04

Tengo el mismo problema con:
Versión de Ansible: 2.0.0.2
Entorno: Ubuntu 14.04

Mismo. Me encontré con esto desde el principio en la fase de configuración.
Versión de Ansible: 2.0.0.2
Versión de Python: 2.7.6
Entorno: Ubuntu 14.04

Solo como una nota, cambié la conexión a paramiko y el problema desapareció y el libro de jugadas funcionó bien. Parece ser un problema con la implementación predeterminada de OpenSSH.

Entonces, para aquellos que tienen este problema, intente usar -c paramiko por ahora, hasta que lo solucionen.

engañado de # 14020

El mensaje de error no es el mismo que el # 14020 y las circunstancias que describo aquí son mucho más amplias. Pero si dices que son iguales, no discutiré.

no es exactamente lo mismo que este en 'ssh' y el otro usando la conexión 'local', pero creo que están relacionados con la 'detección rápida' reescrita, aún así, volverá a abrir esto.

¿Podría alguien publicar un extracto de un libro de jugadas donde ocurre el problema (entiendo que ocurre de manera impredecible; no estoy pidiendo una forma de reproducirlo, solo un poco de contexto), así como la salida de una ejecución fallida con ANSIBLE_DEBUG=y y -vvvvv ?

Tengo el mismo problema con:
Ansible: 2.0.1.0-1ppa ~ preciso
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:

En algún momento funcionó, pero la mayoría FALLÓ.

@nghnam ¿Podría pegar la salida de una ejecución fallida con ANSIBLE_DEBUG = 1 configurado en el entorno?

# 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: "}

Hola amigos, error similar aquí en v2.0.1.0 . -c paramiko sugerido por @bbyhuy funciona siempre, pero la sugerencia de desactivación de multiplexación de @vutoff en # 13278 no me temo. De cualquier manera, creo que uno de estos debería ser marcado como un engaño del otro.

Aquí hay un registro de depuración de ANSIBLE_DEBUG=y ansible all -m ping -vvvvv donde ocurre el problema: https://gist.github.com/oliver/e5a24a5b37c0006bb220

Esto es con Ansible 2.0.1.0-1ppa ~ preciso en Ubuntu 12.04, conectándose a una VM Debian 8.2 que se ejecuta en el host local (por lo que es poco probable que haya problemas de red). Estoy usando become=True y become_method=su , y he agregado la contraseña de root en el archivo hosts con ansible_sudo_pass='pass' . Esta configuración funcionó bien con Ansible 1.9.4-1ppa ~ precisa.

No estoy seguro de si este informe debería ir en # 14426 o # 13278, pero dado que este error no parece estar relacionado con with_items en absoluto (sucede con cualquier libro de jugadas simple e incluso con -m ping ), lo publiqué aquí.

@oliver en su caso, parece una discrepancia en la salida esperada, Passwort: no se está emparejando con el controlador de solicitud su i18n.

@bcoca ¡ Buen truco (y un buen argumento en contra del uso de i18n en un servidor)!
Desafortunadamente, todavía no funciona si configuro $ LANG en una cadena vacía y configuro la configuración regional predeterminada en el sistema de destino en Ninguno. Actualicé el Gist y ahora muestra el mensaje "Contraseña:" que debería reconocerse, pero aún conduce a un tiempo de espera.

Creo que los problemas están en el lado del manejo rápido 'su' (aunque me funciona en mis pruebas).

Aún teniendo el mismo problema (2.0.1.0), msg es

¡HA FALLADO! => {"failed": true, "msg": "Tiempo de espera (12 s) esperando la solicitud de escalada de privilegios:"}

Configuración de mi libro de jugadas

• hosts: dev-server
  
  convertirse en: si
  
  Become_user: root
  
  Become_method: su
  
  * * * * * * * * * * * * * * * * * * * * *
  
  salida de -vvvvv

ESTABLEZCA LA CONEXIÓN SSH PARA EL USUARIO: ubuntu
SSH: ansible.cfg set ssh_args: (-o) (ControlMaster = auto) (- o) (ControlPersist = 60s)
SSH: ANSIBLE_HOST_KEY_CHECKING / host_key_checking deshabilitado: (-o) (StrictHostKeyChecking = no)
SSH: ansible_password / ansible_ssh_pass no establecido: (-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) (Usuario = ubuntu)
SSH: ANSIBLE_TIMEOUT / tiempo de espera establecido: (-o) (ConnectTimeout = 10)
SSH: Conjunto de PlayContext ssh_common_args: ()
SSH: Conjunto de PlayContext ssh_extra_args: ()
SSH: encontrado solo ControlPersist; ControlPath agregado: (-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 = noAuthentication -o Usuario = 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 ")' "'"' '
PONER / tmp / tmpMYXpV0 A /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 deshabilitado: (-o) (StrictHostKeyChecking = no)
SSH: ansible_password / ansible_ssh_pass no establecido: (-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) (Usuario = ubuntu)
SSH: ANSIBLE_TIMEOUT / tiempo de espera establecido: (-o) (ConnectTimeout = 10)
SSH: Conjunto de PlayContext ssh_common_args: ()
SSH: conjunto de PlayContext sftp_extra_args: ()
SSH: encontrado solo ControlPersist; ControlPath agregado: (-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]'
ESTABLEZCA LA CONEXIÓN SSH PARA EL USUARIO: ubuntu
SSH: ansible.cfg set ssh_args: (-o) (ControlMaster = auto) (- o) (ControlPersist = 60s)
SSH: ANSIBLE_HOST_KEY_CHECKING / host_key_checking deshabilitado: (-o) (StrictHostKeyChecking = no)
SSH: ansible_password / ansible_ssh_pass no establecido: (-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) (Usuario = ubuntu)
SSH: ANSIBLE_TIMEOUT / tiempo de espera establecido: (-o) (ConnectTimeout = 10)
SSH: Conjunto de PlayContext ssh_common_args: ()
SSH: Conjunto de PlayContext ssh_extra_args: ()
SSH: encontrado solo ControlPersist; ControlPath agregado: (-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 = noAuthentication -o Usuario = ubuntu -o ConnectTimeout = 10 -o ControlPath = / root / .ansible / cp / ansible-ssh-% h-% p-% r -tt máquina1 '/ 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 '"'" '"'" '"'" '"'" '"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' '"'" '"'" '"'" '" '' "'"' '

Si uso sudo: sí , todo funciona bien.

Ejecutando esto mientras se ejecuta la fase de configuración en un servidor Ubuntu 14.04 EC2 recién iniciado.

Cuando ejecuto por segunda vez la automatización contra el mismo servidor, funciona bien. Sucede todo el tiempo cuando ejecuto por primera vez una automatización de Ansible contra un servidor nuevo

Versión de Ansible: 2.0.1.0
Versión de Python: 2.7.6
Entorno: Ubuntu 14.04

Ejecuto el siguiente comando:

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

consulte la siguiente esencia para la salida: https://gist.github.com/Lowess/77442cf0533629e80b55faa7d6d91eb0

¿Puedo al menos aumentar ese tiempo de espera de 12 segundos de alguna manera?

El "tiempo de espera de 12 segundos" es el timeout configuración + 2s (Ver ssh.py ).

No es una solución, pero establecer el timeout en 30 nos dio un tiempo de espera de escalamiento de 32 segundos que hasta ahora era lo suficientemente bueno (incluso para nuestras instancias AWS EC2 más lentas) para solucionar el error.

@somechris ¡Acabo de probar tu configuración y funcionó!

Por alguna razón, la fase setup tarda entre 20 y 25 segundos. Esa es la primera vez que me enfrento a este tipo de problema mientras ejecuto Ansible contra AWS. Sigo pensando que hay un problema en alguna parte porque con Ansible V1 no necesitaba aumentar ese valor de tiempo de espera.

¡Gracias de nuevo!

Sospecho que el tiempo de espera simplemente no funcionó como se esperaba en v1.

@amenonsen En ese caso, ahora todo tiene sentido para mí. Gracias por la precisión.

Mismo problema.

Ansible Host: Ubuntu 14.04
Managed Hosts: CentOS 7.2

La solución que se describe aquí ha ayudado

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

Los síntomas eran exactamente los mismos (aquí está el syslog de 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 increíble, ¡eso me arregló!

authconfig --disablefingerprint --update

¿Existe un comando equivalente en ubnutu 14.04? Pasándonos también a nosotros

En ansible.cfg, establezca transport = paramiko en la sección [defaults]

En ansible.cfg , lo siguiente ha solucionado el problema para más de 10 implementaciones de servidores con ansible 2.0.1.0:

[defaults]
timeout = 30

Paramiko no parece funcionar con mi configuración de bastión, mientras que ssh funciona como un encanto (menos convertirse / convertirse en usuario / convertirse en método: su). Me está molestando mucho este error, ¿hay algún detalle que pueda proporcionar para ayudar?

<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}

Yo también me pregunto si la configuración es más lenta en 2.x. Vemos tiempos de espera de configuración muy a menudo cuando se ejecuta contra 2.1, pero nunca con 1.9. Hemos aumentado el tiempo de espera a 30, pero aún sucede con bastante frecuencia en 2.1. (Aumentará más para intentar ver si esto es realmente un tiempo de espera o algo que nunca se completará).

Para su información, no hemos visto ese error en un par de meses. Implementamos la solución alternativa de @szhem para nuestros hosts RHEL 6.7 y aparentemente lo solucionó. Para nuestros hosts RHEL 7.2, utilizan una versión más reciente de authconfig (versión 6.2.8-10) que aparentemente soluciona ese problema, porque para ellos no necesitamos la solución alternativa.

También estamos usando RHEL 7.2 en nuestros esclavos Jenkins y servidores Tower.

Ejecutando 2.2 desde la fuente con hosts CentOS 7.2 desde Azure.

Curiosamente, algunas llamadas de servicio de systemd terminan en Timout (12s).

Me deshice de este error agregando nopasswd a mi usuario en / etc / sudoers
username ALL=(ALL) NOPASSWD:ALL

debería estar al final de sudoers

@gandhar He encontrado este error cuando ya tenía activado el nopasswd. Parece que es solo una de las muchas cosas que consumen el tiempo de espera.

¿Intentó depurar su servidor ssh en los nodos? ¿Cuánto tiempo tarda el inicio de sesión ssh en el nodo? Intente agregar UseDNS no al archivo /etc/ssh/sshd_config en los nodos.

• 1
  El problema ocurre cuando implemento más de 3 AWS EC2 al mismo tiempo.
  @somechris gracias por el trabajo, funciona bien incluso en la estrategia: modo libre.

¡HA FALLADO! => {"failed": true, "msg": "Tiempo de espera (12 s) esperando el mensaje de escalada de privilegios:"
SO: CentOS Linux versión 7.2.1511 (Core)
Ansible: ansible 2.2.0

Para el registro. Veo el problema con el firewall FreeBSD PF. El puerto SSH está abierto y la conexión SSH desde una línea de comandos funciona bien. El tiempo de espera desaparece cuando desactivo el firewall.

SOLUCIÓN ALTERNA

./lib/ansible/plugins/connection/ssh.py línea 403 (comete 9fe430867063a0a63316e9bb71e9ba03a475a989):

desde:

timeout = 2 + self._play_context.timeout

a:

timeout = 30 + self._play_context.timeout

CAUSA PRINCIPAL

Los entornos retrasados ​​(nubes públicas, etc.) pueden provocar tiempos de espera debido al estricto tiempo de espera predeterminado. El usuario debe poder configurar el tiempo de espera para que se ajuste a sus necesidades, pero context.timeout no se actualiza al editar ansible.cfg .

plegado en # 13278

mismo problema, agregando become_user: <username>
eliminó el error

Frente a un problema similar, agregar -c paramiko a mi comando ansible-play ayudó a resolver este problema.

Estoy ejecutando ansible 2.1.1.0 y recibí este error. La única forma en que lo hice funcionar fue con lo siguiente en mi libro de jugadas:

remote_user: david
sudo: yes

Y agregando --ask-become-pass al comando.

Novato aquí, estaba teniendo este problema. Corregido con:

sudo:yes

Que reemplazó:

become: yes
become_user: root
become_method: su

Estoy bastante seguro de que es mi propio error de usuario de alguna manera, pero por ahora estoy usando el método obsoleto.

Versión 2.0.0.2

Resulta que estaba usando el método de conversión incorrecto (su), esto funciona usando el valor predeterminado (sudo):

become: yes

Siempre obtengo este error cuando mato ansible (ctrl + c) e intento reiniciar el juego nuevamente. Agregar -c paramiko también resuelve el problema aquí. Después de un tiempo, volverá a funcionar normalmente, así que supongo que algo debe detenerse en el servidor ...
Sin embargo, esto puede ser un problema diferente, porque siempre ocurre al comienzo de la jugada y nunca en momentos aleatorios durante la jugada.

Honestamente, ¿cuál fue el punto de cambiar esto? En el transcurso de lo que parecen 2 revisiones menores, casi todos mis libros de jugadas están rotos. Aparte de convertir todo esto en comportamiento, ansible funcionó perfectamente.

https://github.com/ansible/ansible/issues/14426#issuecomment -205938301 de @somechris sugiere que el tiempo de espera afecta los tiempos de espera de escalada. Sin embargo, la documentación vinculada dice claramente:

Este es el tiempo de espera de SSH predeterminado para usar en los intentos de conexión:

Si las personas informan que el aumento del tiempo de espera está provocando la desaparición de los errores del aviso de escalada, parecería que la documentación está rota o que hay otro problema más siniestro enterrado en algún lugar de ahí.

@tsoikkel hizo un análisis del código real aquí:
https://github.com/ansible/ansible/issues/14426#issuecomment -245256330

Lo que sugiere que la documentación es correcta, pero no sugiere por qué cambiar el tiempo de espera soluciona el problema de escalamiento .

El enlace al que se hace referencia a la confirmación no muestra realmente el código relevante, pero aquí está en el maestro actual:

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

¿El problema de escalada es un tiempo de espera de SSH, un tiempo de espera de ejecución de comando o algo más? De esta discusión no queda claro cuál es la verdadera causa raíz.

Aquí está el código específico que se relaciona con los errores de solicitud de escalamiento:

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

Desafortunadamente, no soy lo suficientemente una persona pitón para poder discernir cuándo sucedería esto. Quizás alguien pueda explicar el flujo aquí, ya que no estoy seguro de por qué alcanzar el timeout en esta instancia particular provocaría que se genere el error.

Al aumentar el tiempo de espera, estamos ocultando la verdadera razón por la que ssh falló en primer lugar con un valor de reintento de 12 segundos que sigue siendo significativo.

¿Alguien sabe por qué Ansible no se conecta al host de forma tan aleatoria? por ejemplo, tenemos 50 nodos en nuestra configuración administrados por ansible y el tiempo de espera ocurre el 3% del tiempo en nodos totalmente aleatorios y tareas aleatorias, y si volvemos a ejecutar el libro de jugadas por segunda vez, estaría bien.

Hola,
perdón por comentar al ticket cerrado.
Experimentamos el mismo problema con ansible 2.2.0 y 2.2.2 y logramos que el problema aparezca solo con Python 3.5. En Python 2.7, todo parece estar bien.

todavía tengo el problema con eso

Tengo este problema. ¿Por qué el problema está cerrado?

Yo también estoy viendo esto. Esto no está arreglado y no debería cerrarse.

Viendo esto en el último ansible. ¿Por qué está cerrado?

También veo esto en 2.3.0

Por favor comente sobre el problema arriba de su comentario. Los mods responderán que esto está cerrado.

Necesitaba eliminar la bandera -n , que estaba causando un problema con sudo 'ing sin contraseña.
Una vez que hice eso, este error comenzó a ocurrir.
Según el comentario de @davidmoshal , cambié become: yes a become: root y mi problema desapareció.

become: root es incorrecto, no establece el usuario, pero termina siendo un True para become por lo que realmente no hay cambios.

Puedo confirmar que volver a ansible1.9 resuelve todos mis extraños problemas de conexión SSH. No sé qué está mal con ansible2.x, pero no actualizaré pronto, ya que parece que esto persiste. He visto comentarios de que esto no es un error ansible y estoy totalmente en desacuerdo. La única variable que he cambiado es una actualización ansible. Administro más de 70 servidores sin problemas con ansible1.9, ansible 2.0 falla con cada instancia que tengo. Este es un error ansible. No ssh ni ninguna otra capa.

Acabo de tener este problema para mí, estaba sucediendo 4-5 veces seguidas. Ansible 2.3, Ubuntu 16.04.1.
Pero como no he tenido ningún problema hoy en el área donde comenzó a suceder y no hice ningún cambio allí, comencé a pensar que algo va mal con el nodo de control en sí.
Decidí reiniciar el nodo de control e intentarlo de nuevo y funcionó para mí sin problemas. El problema desapareció.

También tengo este mismo problema con 2.3.0.0 y 2.4.1.0 con canalización. Debido a una mala configuración por nuestra parte, la canalización se había deshabilitado por accidente durante un tiempo (no estoy seguro de cuánto tiempo, sospecho que el cambio anterior a 2.0), pero habilitarlo nuevamente resultó en el tiempo de espera de la solicitud de escalada de privilegios mencionado aquí.

Yo uso simplemente become = True y become_method = sudo . Lo único 'especial' que realmente hago es configurar el ANSIBLE_SSH_ARGS para que escriba UserKnownHostsFile en una ubicación personalizada específica, pero dudo que esto afecte a algo.

Intenté cambiar a paramiko, pero se bloqueó y se quemó por completo en mi configuración de prueba y el aumento de los tiempos de espera tampoco funcionó, falló tanto en mi configuración de prueba como en nuestro entorno de producción.

Preparar:

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

Obtiene este error aleatoriamente al probar un libro de jugadas, la última vez que fue durante una acción de archivo (la carpeta ya existía). Las dos máquinas virtuales tienen el mismo usuario "vagabundo" y la caja de Solaris no tiene contraseña de root.

Usé --ask-Become-pass y presioné ENTER. Aún así, el error ocurrió ...

En mi caso, fue un problema real (no un error) en mi servidor donde DNS no se resolvería. sudo aparentemente usa DNS para resolver el nombre de host de la máquina, y si esto falla, se agotará el tiempo de espera. Lo arreglé corrigiendo la entrada DNS en mi /etc/resolv.conf.

Tener este problema a menudo en GCE con Ansible 2.5 de git también. Hasta ahora, usar paramiko parece ser una solución viable.

Tuve que killall ssh , tal vez una conexión ssh obsoleta si estás usando ControlPersist .

Hola, tengo el mismo problema con la implementación en ubuntu 16.04 con ansible 2.4.2.0, la opción --paramiko resuelve el problema, pero en el mismo caso no lea mi ~ / .ssh / config, así que en lugar de la opción --paramiko resuelvo deshabilitar la opción de canalización (de forma predeterminada es Falso) en el archivo ansible.cfg agregar:

[ssh_connection]
pipelining = False

Experimenté el mismo problema al intentar ejecutar un libro de jugadas en un contenedor LXD Ubuntu 16.04. Podría ingresar al contenedor bien, pero tomaría mucho tiempo sudo su y generaría un error sudo: unable to resolve host ingest0: Connection timed out .

Agregué el nombre de host a /etc/hosts y el problema desapareció: podía ejecutar el libro de jugadas sin que se agotara el tiempo de escalada y podía sudo su inmediatamente.

root<strong i="11">@ingest0</strong>:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 ingest0

Estoy usando ansible 2.4.3.0 y python 2.7.12 .

mi problema se resolvió cambiando el archivo de hosts de

[sandbox]
fedora<strong i="6">@ip</strong>

a

[sandbox]
ip

donde ip es la dirección IP de la máquina.

¿Por qué está cerrado?
Acabo de configurar un nuevo servidor Ubuntu con las últimas Ansible y Python y el error sigue ahí.
Ninguna de las soluciones funciona.

¿Por qué está cerrado?

Probablemente porque no es posible preguntar a todos los usuarios si las soluciones funcionan. Por cierto, es probable que haya varias causas diferentes del error. La persona hizo un llamado a juicio para cerrar el asunto.

Estoy de acuerdo,

Estoy teniendo el mismo problema, le he dado root al usuario sudoers ... He forzado el cambio de usuarios.

Nada funciona y es un error razonable investigar. ¿Quizás se requiera un mejor manejo de excepciones aquí?

Mi libro de jugadas se ve así:

• hosts: localhost

convertirse_usuario: jenkins
reunir_factos: verdadero
roles:
- {rol: bareos, etiquetas: local}

• hosts: dev-cluster
  usuario_remoto: centos
  reunir_factos: verdadero
  roles:

  • {rol: bareos, etiquetas: cliente}

• hosts: copia de seguridad
  usuario_remoto: centos
  Become_user: root
  reunir_factos: verdadero
  roles:

  • {rol: bareos, etiquetas: servidor}

Todos los demás hosts funcionan excepto los hosts: copia de seguridad.

-Espectáculos vvv

Usando el archivo de módulo /usr/lib/python2.7/site-packages/ansible/modules/system/setup.py
ESTABLEZCA LA CONEXIÓN SSH PARA EL USUARIO: 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 '"'" '"'" '"'" '"'" '&& dormir 0' "'"' '

El servidor está en AWS.
Tengo en mi ansible comando

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

Acabo de tener este problema, esto se convierte en usuario y copia del modelo. sin embargo, cuando uso el libro de jugadas de ejecución directa de root, está bien.

mensaje de error:

SSH: EXEC sshpass -d13 ssh -C -o ControlMaster = auto -o ControlPersist = 60s -o StrictHostKeyChecking = no -o Usuario = 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 '"'" '"'" '"'" '"'" '"'" '"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' "'"' "''" '"'" '"'" '&& dormir 0 '"'" ''
fatal: [192.168.202.105]: ¡FALLÓ! => {
"msg": "Tiempo de espera (22 s) esperando la solicitud de escalamiento de privilegios:"

Estoy de acuerdo,

Estoy teniendo el mismo problema, le he dado root al usuario sudoers ... He forzado el cambio de usuarios.

Nada funciona y es un error razonable investigar. ¿Quizás se requiera un mejor manejo de excepciones aquí?

Mi libro de jugadas se ve así:

• hosts: localhost

convertirse_usuario: jenkins
reunir_factos: verdadero
roles:

• {rol: bareos, etiquetas: local}

• hosts: dev-cluster
  usuario_remoto: centos
  reunir_factos: verdadero
  roles:

  • {rol: bareos, etiquetas: cliente}

• hosts: copia de seguridad
  usuario_remoto: centos
  Become_user: root
  reunir_factos: verdadero
  roles:

  • {rol: bareos, etiquetas: servidor}

Todos los demás hosts funcionan excepto los hosts: copia de seguridad.

-Espectáculos vvv

Usando el archivo de módulo /usr/lib/python2.7/site-packages/ansible/modules/system/setup.py
ESTABLEZCA LA CONEXIÓN SSH PARA EL USUARIO: 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 '"'" '"'" '"'" '"'" '&& dormir 0' "'"' '

El servidor está en AWS.
Tengo en mi ansible comando

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

>

Mi problema estaba relacionado con el firewall. Para mí esto está resuelto.

Para mí, fue por la mala conexión a Internet.

También recibo este problema:
Libro de jugadas:

- 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 }}"

Lo que da el error:

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

El libro de jugadas tiene muchas otras tareas que se realizan sin problemas. Solo este con las diferentes opciones de "convertirse", falla.

Mis 3 centavos:
Problema similar aquí. Mismo error. No tuve tiempo para depurar pero lo que vi:

1) Esto está relacionado con la red (mi conexión es a través del túnel HE6 a Ubunut 18.04-> LXD containter). Con una configuración de túnel, el mismo error que el anterior. Con otra configuración de túnel funciona bien (supongo que aquí, pero probablemente se trate de un problema de MTU de algún tipo).

1. ANSIBLE_SSH_ARGS = "- o ControlMaster = no" ayuda un poco - la conexión se atasca en una tarea diferente cuando se usa.