Ansible: ERROR! Zeitüberschreitung (12 Sekunden), die auf die Aufforderung zur Eskalation von Berechtigungen wartet:

Genau das gleiche Problem für mich: besorgt:.

Ansible Version: 2.0.0.2
Python-Version: 2.7.6
Umgebung: Ubuntu 14.04

Ich habe das gleiche Problem mit:
Ansible Version: 2.0.0.2
Umgebung: Ubuntu 14.04

Gleich. Dies zu Beginn der Setup-Phase.
Ansible Version: 2.0.0.2
Python-Version: 2.7.6
Umgebung: Ubuntu 14.04

Nur als Hinweis, ich habe die Verbindung auf paramiko umgestellt und das Problem ist verschwunden und das Playbook lief einwandfrei. Scheint ein Problem mit der Standard-OpenSSH-Implementierung zu sein.

Wenn Sie dieses Problem haben, versuchen Sie zunächst, -c paramiko zu verwenden, bis das Problem behoben ist.

Betrogener von # 14020

Die Fehlermeldung ist nicht mit # 14020 identisch und die Umstände, die ich hier beschreibe, sind viel umfassender. Aber wenn Sie sagen, dass sie gleich sind, werde ich nicht streiten.

es ist nicht genau das gleiche wie dies auf 'ssh' und das andere über 'lokale' Verbindung ist, aber ich glaube, dass sie mit der umgeschriebenen 'sofortigen Erkennung' zusammenhängen, wird dies dennoch wieder öffnen.

Könnte jemand bitte einen Auszug aus einem Playbook posten, in dem das Problem auftritt (ich verstehe, dass es unvorhersehbar auftritt; ich frage nicht nach einer Möglichkeit, es zu reproduzieren, nur nach einem bestimmten Kontext) sowie die Ausgabe eines fehlgeschlagenen Laufs mit ANSIBLE_DEBUG=y und -vvvvv ?

Ich habe das gleiche Problem mit:
Ansible: 2.0.1.0-1ppa ~ genau
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:

Irgendwann hat es funktioniert, aber das meiste war gescheitert.

@nghnam Könnten Sie bitte die Ausgabe eines fehlgeschlagenen Laufs mit ANSIBLE_DEBUG = 1 in der Umgebung einfügen?

# 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 Leute, ähnlicher Fehler hier auf v2.0.1.0 . -c paramiko vorgeschlagen von @bbyhuy funktioniert jedes Mal , aber das @vutoff ‚s zu deaktivieren Multiplexen Vorschlag in # 13278 nicht fürchte mich. Wie auch immer, ich denke, einer von diesen sollte als Betrüger des anderen markiert werden?

Hier ist ein Debug-Protokoll von ANSIBLE_DEBUG=y ansible all -m ping -vvvvv in dem das Problem auftritt: https://gist.github.com/oliver/e5a24a5b37c0006bb220

Dies ist mit Ansible 2.0.1.0-1ppa ~ genau unter Ubuntu 12.04 und stellt eine Verbindung zu einer Debian 8.2-VM her, die auf dem lokalen Host ausgeführt wird (Netzwerkprobleme sind daher unwahrscheinlich). Ich verwende become=True und become_method=su und habe das Root-Passwort in der Datei hosts mit ansible_sudo_pass='pass' hinzugefügt. Dieses Setup funktionierte gut mit Ansible 1.9.4-1ppa ~ präzise.

Ich bin mir nicht sicher, ob dieser Bericht bei # 14426 oder # 13278 erscheinen soll, aber da dieser Fehler überhaupt nicht mit with_items zu tun zu haben scheint (es kommt bei jedem einfachen Playbook vor und sogar bei -m ping ), habe ich ihn gepostet Hier.

@oliver In Ihrem Fall scheint die erwartete Ausgabe nicht Passwort: wird nicht mit dem Eingabeaufforderungshandler su i18n abgeglichen.

@bcoca Guter Fang (und ein gutes Argument gegen die Verwendung von i18n auf einem Server)!
Leider funktioniert es immer noch nicht, wenn ich $ LANG auf eine leere Zeichenfolge setze und das Standardgebietsschema auf dem Zielsystem auf Keine setze. Ich habe das Gist aktualisiert und es wird jetzt die Eingabeaufforderung "Passwort:" angezeigt, die erkannt werden sollte, aber dennoch zu einer Zeitüberschreitung führt.

Ich glaube, das Problem liegt auf der Seite der sofortigen Behandlung (obwohl es bei meinen Tests für mich funktioniert).

Msg hat immer noch das gleiche Problem (2.0.1.0)

GESCHEITERT! => {"failed": true, "msg": "Timeout (12s) wartet auf Eingabeaufforderung zur Eskalation von Berechtigungen:"}

Mein Spielbuch Konfiguration

• Hosts: Dev-Server
  
  werden: ja
  
  werden_benutzer: root
  
  werden_Methode: su
  
  * * * * * * * * * * * * * * * * * * * * * *
  
  Ausgabe von -vvvvv

SSH-VERBINDUNG FÜR BENUTZER FESTLEGEN: ubuntu
SSH: ansible.cfg setze ssh_args: (-o) (ControlMaster = auto) (- o) (ControlPersist = 60s)
SSH: ANSIBLE_HOST_KEY_CHECKING / host_key_checking deaktiviert: (-o) (StrictHostKeyChecking = no)
SSH: ansible_password / ansible_ssh_pass nicht festgelegt: (-o) (KbdInteractiveAuthentication = no) (- o) (PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbasiert, publickey) (- o) (PasswordAuthentication = no)
SSH: ANSIBLE_REMOTE_USER / remote_user / ansible_user / user / -u set: (-o) (User = ubuntu)
SSH: ANSIBLE_TIMEOUT / Timeout gesetzt: (-o) (ConnectTimeout = 10)
SSH: PlayContext set ssh_common_args: ()
SSH: PlayContext set ssh_extra_args: ()
SSH: nur ControlPersist gefunden; ControlPath hinzugefügt: (-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, hostbasiert, publickey -o PasswordAent -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 setze ssh_args: (-o) (ControlMaster = auto) (- o) (ControlPersist = 60s)
SSH: ANSIBLE_HOST_KEY_CHECKING / host_key_checking deaktiviert: (-o) (StrictHostKeyChecking = no)
SSH: ansible_password / ansible_ssh_pass nicht festgelegt: (-o) (KbdInteractiveAuthentication = no) (- o) (PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbasiert, publickey) (- o) (PasswordAuthentication = no)
SSH: ANSIBLE_REMOTE_USER / remote_user / ansible_user / user / -u set: (-o) (User = ubuntu)
SSH: ANSIBLE_TIMEOUT / Timeout gesetzt: (-o) (ConnectTimeout = 10)
SSH: PlayContext set ssh_common_args: ()
SSH: PlayContext set sftp_extra_args: ()
SSH: nur ControlPersist gefunden; ControlPath hinzugefügt: (-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, hostbasiert, publickey -o PasswordAuthentication = no -o User = ubuntu -o ConnectTimeout = 10 -o ControlPath = / root / .ansible / cp / ansible-ssh-% h-% p-% r '[machine1]'
SSH-VERBINDUNG FÜR BENUTZER FESTLEGEN: ubuntu
SSH: ansible.cfg setze ssh_args: (-o) (ControlMaster = auto) (- o) (ControlPersist = 60s)
SSH: ANSIBLE_HOST_KEY_CHECKING / host_key_checking deaktiviert: (-o) (StrictHostKeyChecking = no)
SSH: ansible_password / ansible_ssh_pass nicht festgelegt: (-o) (KbdInteractiveAuthentication = no) (- o) (PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbasiert, publickey) (- o) (PasswordAuthentication = no)
SSH: ANSIBLE_REMOTE_USER / remote_user / ansible_user / user / -u set: (-o) (User = ubuntu)
SSH: ANSIBLE_TIMEOUT / Timeout gesetzt: (-o) (ConnectTimeout = 10)
SSH: PlayContext set ssh_common_args: ()
SSH: PlayContext set ssh_extra_args: ()
SSH: nur ControlPersist gefunden; ControlPath hinzugefügt: (-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, hostbasiert, publickey -o PasswordAent -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 '' '' '' '' '' '' '' '' '' ' "'"' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' ' '' "'"' '

Wenn ich sudo benutze

Dies wird ausgeführt, während die Setup-Phase auf einem neu gestarteten Ubuntu 14.04 EC2-Server ausgeführt wird.

Wenn ich die Automatisierung ein zweites Mal auf demselben Server ausführe, funktioniert sie einwandfrei. Es passiert die ganze Zeit, wenn ich zum ersten Mal eine Ansible-Automatisierung gegen einen neuen Server ausführe

Ansible Version: 2.0.1.0
Python-Version: 2.7.6
Umgebung: Ubuntu 14.04

Ich führe den folgenden Befehl aus:

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

Die Ausgabe finden Sie in der folgenden Übersicht: https://gist.github.com/Lowess/77442cf0533629e80b55faa7d6d91eb0

Kann ich das 12-Sekunden-Timeout zumindest irgendwie erhöhen?

Das "12-Sekunden-Zeitlimit" ist die timeout -Konfigurationseinstellung + 2s (siehe ssh.py ).

Es ist keine Lösung, aber das Setzen von timeout auf 30 führte zu einem Eskalationszeitlimit von 32 Sekunden, das bisher gut genug war (selbst für unsere langsameren AWS EC2-Instanzen), um den Fehler zu umgehen.

@somechris Ich habe gerade deine Einstellung ausprobiert und es hat funktioniert!

Aus irgendeinem Grund dauert die setup -Phase etwa 20 - 25 Sekunden. Dies ist das erste Mal, dass ich beim Ausführen von Ansible gegen AWS auf solche Probleme stoße. Ich denke immer noch, dass es irgendwo ein Problem gibt, weil ich mit Ansible V1 diesen Timeout-Wert nicht erhöhen musste.

Danke noch einmal!

Ich vermute, dass das Timeout in Version 1 einfach nicht wie beabsichtigt funktioniert hat.

@amenonsen In diesem Fall machen alle jetzt Sinn für mich. Danke für die Präzision.

Gleicher Fehler.

Ansible Host: Ubuntu 14.04
Managed Hosts: CentOS 7.2

Die hier beschriebene Problemumgehung hat geholfen

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

Die Symptome waren genau die gleichen (hier ist das Syslog von 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 super , das hat es für mich behoben!

authconfig --disablefingerprint --update

Gibt es einen äquivalenten Befehl für ubnutu 14.04? Passiert auch uns

Setzen Sie in ansible.cfg im Abschnitt [Standardeinstellungen] transport = paramiko

In ansible.cfg wurde das Problem bei mehr als 10 Serverbereitstellungen mit ansible 2.0.1.0 durch Folgendes behoben:

[defaults]
timeout = 30

Paramiko scheint nicht mit meiner Bastionskonfiguration zu funktionieren, während ssh wie ein Zauber wirkt (minus werden / werden_benutzer / werden_methode: su). Ich bin von diesem Fehler schwer betroffen. Gibt es Details, die ich zur Verfügung stellen kann, um zu helfen?

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

Ich frage mich auch, ob das Setup in 2.x nur langsamer ist. Wir sehen sehr oft Setup-Timeouts, wenn wir gegen 2.1 laufen, aber niemals mit 1.9. Wir haben das Timeout auf 30 erhöht, aber es kommt immer noch ziemlich häufig bei 2.1 vor. (Erhöht sich weiter, um festzustellen, ob dies wirklich eine Zeitüberschreitung ist oder etwas, das niemals abgeschlossen wird.)

Zu Ihrer Information, wir haben diesen Fehler seit ein paar Monaten nicht mehr gesehen. Wir haben die Problemumgehung von

Wir verwenden RHEL 7.2 auch auf unseren Jenkins-Slaves und Tower-Servern.

Ausführen von 2.2 aus dem Quellcode mit CentOS 7.2-Hosts aus Azure.

Seltsamerweise führen einige systemd Service-Aufrufe zu Timout (12s).

Ich habe diesen Fehler behoben, indem ich meinem Benutzer in / etc / sudoers nopasswd hinzugefügt habe
username ALL=(ALL) NOPASSWD:ALL

sollte am Ende von Sudoers sein

@gandhar Ich bin auf diesen Fehler gestoßen, während der nopasswd bereits aktiviert war. Sieht so aus, als wäre es nur eines von vielen Dingen, die das Timeout verbrauchen.

Haben Sie versucht, Ihren SSH-Server an Knoten zu debuggen? Wie viel Zeit benötigt die SSH-Anmeldung am Knoten? Versuchen Sie, UseDNS no zu /etc/ssh/sshd_config Datei auf den Knoten hinzuzufügen.

• 1
  Das Problem tritt auf, wenn ich mehr als 3 AWS EC2 gleichzeitig bereitstelle.
  @somechris danke für die

GESCHEITERT! => {"failed": true, "msg": "Timeout (12s) wartet auf Eingabeaufforderung zur Eskalation von Berechtigungen:"
Betriebssystem: CentOS Linux Version 7.2.1511 (Core)
Ansible: ansible 2.2.0

Für die Aufzeichnung. Ich sehe das Problem mit der FreeBSD PF-Firewall. Der SSH-Port ist offen und die SSH-Verbindung über eine Befehlszeile funktioniert einwandfrei. Das Zeitlimit verschwindet, wenn ich die Firewall deaktiviere.

Umgehung

./lib/ansible/plugins/connection/ssh.py Zeile 403 (Commit 9fe430867063a0a63316e9bb71e9ba03a475a989):

von:

timeout = 2 + self._play_context.timeout

zu:

timeout = 30 + self._play_context.timeout

URSACHE

Laggy-Umgebungen (öffentliche Clouds usw.) können aufgrund strenger Standardzeitüberschreitungen zu Zeitüberschreitungen führen. Der Benutzer sollte in der Lage sein, das Zeitlimit so zu konfigurieren, dass es seinen Anforderungen entspricht, aber context.timeout wird beim Bearbeiten von ansible.cfg nicht aktualisiert.

Falten in # 13278

das gleiche Problem, Hinzufügen von become_user: <username>
Fehler behoben

Angesichts eines ähnlichen Problems hat das Hinzufügen von -c paramiko zu meinem Ansible-Play-Befehl zur Behebung dieses Problems beigetragen.

Ich verwende ansible 2.1.1.0 und habe diesen Fehler erhalten. Die einzige Möglichkeit, es zum Laufen zu bringen, war die folgende in meinem Spielbuch:

remote_user: david
sudo: yes

Und das Hinzufügen von --ask-become-pass zum Befehl.

Neuling hier hatte dieses Problem. Behoben mit:

sudo:yes

Welches ersetzt:

become: yes
become_user: root
become_method: su

Ich bin mir ziemlich sicher, dass es irgendwie mein eigener Benutzerfehler ist, aber im Moment verwende ich die veraltete Methode.

Version 2.0.0.2

Es stellte sich heraus, dass ich die falsche Methode find_method (su) verwendet habe. Dies funktioniert mit default (sudo):

become: yes

Ich erhalte immer diesen Fehler, wenn ich ansible töte (Strg + c) und versuche, das Spiel erneut zu starten. Das Hinzufügen von -c paramiko löst das Problem auch hier. Nach einer Weile funktioniert es wieder normal, daher muss auf dem Server eine Zeitüberschreitung auftreten ...
Dies kann jedoch ein anderes Problem sein, da es immer zu Beginn des Spiels und niemals zu zufälligen Zeiten während des Spiels auftritt.

Was war überhaupt der Grund, dies zu ändern? Im Verlauf von 2 kleinen Revisionen sind derzeit fast alle meine Playbooks kaputt. Abgesehen davon, dass all dies zu Verhalten wurde, funktionierte ansible einwandfrei.

https://github.com/ansible/ansible/issues/14426#issuecomment -205938301 von @somechris legt nahe, dass das Zeitlimit die Eskalationszeitlimits beeinflusst. In der verknüpften Dokumentation heißt es jedoch eindeutig:

Dies ist das Standard-SSH-Zeitlimit für Verbindungsversuche:

Wenn Leute berichten, dass das Erhöhen des Timeouts dazu führt, dass die Fehler bei der Eskalationsaufforderung verschwinden, scheint die Dokumentation fehlerhaft zu sein, oder irgendwo dort ist ein weiteres unheimlicheres Problem begraben.

@tsoikkel hat hier eine Analyse des tatsächlichen Codes vorgenommen:
https://github.com/ansible/ansible/issues/14426#issuecomment -245256330

Dies deutet darauf hin, dass die Dokumentation korrekt ist, aber nicht darauf, warum das Ändern des Zeitlimits das Eskalationsproblem behebt.

Der Link, auf den verwiesen wird, zeigt nicht den relevanten Code an, aber hier befindet er sich im aktuellen Master:

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

Ist das Eskalationsproblem ein SSH-Zeitlimit oder ein Befehlsausführungszeitlimit oder etwas anderes? Aus dieser Diskussion geht nicht hervor, was die eigentliche Grundursache ist.

Hier ist der spezifische Code, der sich auf Eskalationsaufforderungsfehler bezieht:

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

Leider bin ich nicht genug von einer Python-Person, um erkennen zu können, wann dies passieren würde. Vielleicht kann hier jemand den Ablauf erklären, da ich nicht sicher bin, warum das Erreichen des Werts timeout in diesem speziellen Fall dazu führen würde, dass der Fehler ausgelöst wird.

Indem wir das Timeout erhöhen, verbergen wir den wahren Grund, warum ssh auf einem ersten Platz mit einem 12s-Wiederholungswert fehlgeschlagen ist, der immer noch signifikant ist.

Ist jemandem bekannt, warum ansible keine zufällige Verbindung zum Host herstellt? Zum Beispiel haben wir 50 Knoten in unserem Setup, die von ansible verwaltet werden, und Timeout tritt in 3% der Fälle bei völlig zufälligen Knoten und zufälligen Aufgaben auf. Wenn wir das Playbook zum zweiten Mal erneut ausführen, ist dies in Ordnung.

Hallo,
Entschuldigung für den Kommentar zum geschlossenen Ticket.
Wir hatten das gleiche Problem mit ansible 2.2.0 und 2.2.2 und wir haben es geschafft, dass das Problem nur mit Python 3.5 auftritt. In Python 2.7 scheint alles in Ordnung zu sein.

habe immer noch das Problem damit

Ich habe dieses Problem. Warum ist die Ausgabe geschlossen?

Ich sehe das auch. Dies ist nicht behoben und sollte nicht geschlossen werden.

Sehen Sie dies in der neuesten ansible. Warum ist das geschlossen?

Ich sehe das auch in 2.3.0

Bitte kommentieren Sie das Problem über Ihrem Kommentar. Die Mods werden antworten, dass dies geschlossen ist.

Ich musste das Flag -n entfernen, was ein Problem mit sudo ohne Passwort verursachte.
Sobald ich das getan habe, trat dieser Fehler auf.
Gemäß dem Kommentar von become: yes in become: root geändert und mein Problem ist verschwunden .

become: root ist falsch, es legt den Benutzer nicht fest, aber es wird ein True Wert für become also ist es wirklich keine Änderung.

Ich kann bestätigen, dass das Zurücksetzen auf ansible1.9 alle meine seltsamen SSH-Verbindungsprobleme behebt. Ich weiß nicht, was mit ansible2.x nicht stimmt, aber ich werde in Kürze kein Upgrade durchführen, da dies weiterhin zu bestehen scheint. Ich habe Kommentare gesehen, dass dies kein ansiblicher Fehler ist, und ich bin absolut anderer Meinung. Die einzige Variable, die ich geändert habe, ist ein ansibles Upgrade. Ich verwalte über 70 Server ohne Probleme mit ansible1.9, ansible 2.0 schlägt mit jeder Instanz fehl, die ich habe. Dies ist ein ansible Fehler. Nicht ssh oder irgendeine andere Schicht.

Hatte gerade dieses Problem für mich, es passierte 4-5 mal hintereinander. Ansible 2.3, Ubuntu 16.04.1.
Aber da ich heute keine Probleme in dem Bereich hatte, in dem es angefangen hat, und dort keine Änderungen vorgenommen habe, habe ich gerade angefangen zu denken, dass etwas mit dem steuernden Knoten selbst schief geht.
Ich habe beschlossen, den Steuerungsknoten neu zu starten und es erneut zu versuchen, und es hat bei mir ohne Probleme funktioniert. Das Problem ist weg.

Haben Sie auch das gleiche Problem mit 2.3.0.0 und 2.4.1.0 mit Pipelining. Aufgrund einer Fehlkonfiguration auf unserer Seite war das Pipelining bereits seit einiger Zeit versehentlich deaktiviert (nicht sicher, wie lange ich einen Wechsel vor 2.0 vermute), aber das erneute Aktivieren führte zu dem hier erwähnten Zeitlimit für die Aufforderung zur Eskalation von Berechtigungen.

Ich benutze einfach become = True und become_method = sudo . Das einzige, was ich wirklich mache, ist, die ANSIBLE_SSH_ARGS so einzustellen, dass sie UserKnownHostsFile an einen bestimmten benutzerdefinierten Ort schreiben - aber ich bezweifle, dass dies irgendetwas beeinflussen würde?

Ich habe versucht, zu paramiko zu wechseln, aber das stürzte in meinem Test-Setup ab und brannte vollständig. Das Erhöhen der Zeitüberschreitungen funktionierte auch nicht. Es schlug sowohl in meinem Test-Setup als auch in unserer Produktionsumgebung fehl.

Konfiguration:

• Ansible 2.4.0 Ubuntu 16.04-Steuerungsmaschine VirtualBox 5.1.30 VM (Vagrantbox: bento / ubuntu-16.04)
• Solaris 11.3 VirtualBox 5.1.30 VM (Vagrantbox: HeavyBeans / Solaris11-Small-Server)

Beim Testen eines Playbooks wird dieser Fehler zufällig angezeigt, zuletzt während einer Dateiaktion (der Ordner war bereits vorhanden). Die beiden VMs haben denselben Benutzer "vagrant" und die Solaris-Box hat kein Root-Passwort.

Ich habe --ask-come-pass verwendet und ENTER gedrückt. Trotzdem ist der Fehler passiert ...

In meinem Fall war es ein echtes Problem (kein Fehler) auf meinem Server, bei dem DNS nicht behoben werden konnte. sudo verwendet anscheinend DNS, um den Hostnamen des Computers aufzulösen. Wenn dies fehlschlägt, tritt eine Zeitüberschreitung auf. Ich habe es behoben, indem ich den DNS-Eintrag in meiner /etc/resolv.conf korrigiert habe.

Dieses Problem tritt häufig auch in GCE mit Ansible 2.5 von git auf. Bisher scheint die Verwendung von Paramiko eine praktikable Problemumgehung zu sein.

Ich musste killall ssh , vielleicht eine veraltete SSH-Verbindung, wenn Sie ControlPersist .

Hallo, ich habe die gleichen Probleme bei der Bereitstellung auf Ubuntu 16.04 mit ansible 2.4.2.0, die Option --paramiko löst das Problem, aber im gleichen Fall lese ich nicht meine ~ / .ssh / config, also löse ich anstelle der Option --paramiko Deaktivieren der Option Pipelining (standardmäßig ist False) in der ansible.cfg hinzufügen:

[ssh_connection]
pipelining = False

Das gleiche Problem trat auf, als ich versuchte, ein Playbook auf einem LXD Ubuntu 16.04-Container auszuführen. Ich könnte gut in den Container ssh, aber es würde lange dauern, bis sudo su und es würde sudo: unable to resolve host ingest0: Connection timed out Fehler machen.

Ich habe den Hostnamen zu /etc/hosts hinzugefügt und das Problem ist behoben - ich konnte das Playbook ausführen, ohne dass es zu einer Eskalation kam, und ich konnte sofort sudo su .

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

Ich verwende ansible 2.4.3.0 und python 2.7.12 .

Mein Problem wurde durch Ändern der Hosts-Datei von behoben

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

zu

[sandbox]
ip

Dabei ist IP die IP-Adresse des Computers.

Warum ist das geschlossen?
Ich habe gerade einen brandneuen Ubuntu-Server mit den neuesten Ansible und Python eingerichtet und der Fehler ist immer noch da.
Keine der Problemumgehungen funktioniert.

Warum ist das geschlossen?

Wahrscheinlich, weil nicht jeder Benutzer gefragt werden kann, ob die Lösung (en) funktionieren. Im Übrigen gibt es wahrscheinlich mehrere verschiedene Fehlerursachen. Die Person machte ein Urteil, um das Problem zu schließen.

Genau,

Ich habe das gleiche Problem, ich habe dem Benutzer sudoers root gegeben .... Ich habe den Benutzerwechsel erzwungen.

Nichts funktioniert und vernünftige Fehler zu untersuchen. Vielleicht ist hier eine bessere Ausnahmebehandlung erforderlich?

Mein Spielbuch sieht so aus:

• Gastgeber: localhost

werden_benutzer: jenkins
collect_facts: true
Rollen:
- {Rolle: Bareos, Tags: lokal}

• Hosts: Dev-Cluster
  remote_user: centos
  collect_facts: true
  Rollen:

  • {Rolle: Bareos, Tags: Client}

• Hosts: Backup
  remote_user: centos
  werden_benutzer: root
  collect_facts: true
  Rollen:

  • {Rolle: Bareos, Tags: Server}

Alle anderen Hosts außer den Hosts funktionieren: Backup.

-vvv Shows

Verwenden der Moduldatei /usr/lib/python2.7/site-packages/ansible/modules/system/setup.py
SSH-VERBINDUNG FÜR BENUTZER FESTLEGEN: Centos
SSH: EXEC ssh -o ControlMaster = auto -o ControlPersist = 30m -o Verbindungsversuche = 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, hostbasiert, publickey -o PasswordAuthentication = no -o Benutzer = 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 ist in AWS.
Ich habe in meinem ansible Befehl

ansible-playbook -vvv -i inventar / hosts bareos.yml - Schlüsseldatei "~ / .ssh / demo.pem" -b -e

Ich habe nur dieses Problem - diese Genauigkeit wird Benutzer- und Modellkopie. Wenn ich jedoch Root Direct Run Playbook verwende, ist das in Ordnung.

Fehlermeldung:

SSH: EXEC sshpass -d13 ssh -C -o ControlMaster = auto -o ControlPersist = 60s -o StrictHostKeyChecking = no -o Benutzer = vmuser -o ConnectTimeout = 20 -o ControlPath = / root / .ansible / cp / 48d4a08c2f -tt 192.168 .202.105 '/ bin / sh -c' '' 'su root -c' '' '' '' '' '' '' '' / bin / sh -c '' '' '' '' ' "'"' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' 'BECOME-SUCCESS-fkekucjxphrobughycoiecflsoiptmkg ;; / usr / bin / python /home/vmuser/.ansible/tmp/ansible-tmp-1536311364.58-186480404230053/file.py '' '' '' '' '' '' '' '' '' '' '' '' "'"' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' && sleep 0 '"'" ''
tödlich: [192.168.202.105]: FEHLGESCHLAGEN! => {
"msg": "Timeout (22s) wartet auf Aufforderung zur Eskalation von Berechtigungen:"

Genau,

Ich habe das gleiche Problem, ich habe dem Benutzer sudoers root gegeben .... Ich habe den Benutzerwechsel erzwungen.

Nichts funktioniert und vernünftige Fehler zu untersuchen. Vielleicht ist hier eine bessere Ausnahmebehandlung erforderlich?

Mein Spielbuch sieht so aus:

• Gastgeber: localhost

werden_benutzer: jenkins
collect_facts: true
Rollen:

• {Rolle: Bareos, Tags: lokal}

• Hosts: Dev-Cluster
  remote_user: centos
  collect_facts: true
  Rollen:

  • {Rolle: Bareos, Tags: Client}

• Hosts: Backup
  remote_user: centos
  werden_benutzer: root
  collect_facts: true
  Rollen:

  • {Rolle: Bareos, Tags: Server}

Alle anderen Hosts außer den Hosts funktionieren: Backup.

-vvv Shows

Verwenden der Moduldatei /usr/lib/python2.7/site-packages/ansible/modules/system/setup.py
SSH-VERBINDUNG FÜR BENUTZER FESTLEGEN: Centos
SSH: EXEC ssh -o ControlMaster = auto -o ControlPersist = 30m -o Verbindungsversuche = 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, hostbasiert, publickey -o PasswordAuthentication = no -o Benutzer = 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 ist in AWS.
Ich habe in meinem ansible Befehl

ansible-playbook -vvv -i inventar / hosts bareos.yml - Schlüsseldatei "~ / .ssh / demo.pem" -b -e

>

Mein Problem betraf die Firewall. Für mich ist das gelöst.

Für mich lag es an der schlechten Internetverbindung.

Ich bekomme auch dieses Problem:
Spielbuch:

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

Welches gibt den Fehler:

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

Das Spielbuch hat viele andere Aufgaben, die ohne Probleme erledigt werden. Nur dieser mit den verschiedenen "Werden" -Optionen schlägt fehl.

Meine 3 Cent:
Ähnliches Problem hier. Gleicher Fehler. Ich hatte keine Zeit zum Debuggen, aber was ich entdeckte:

1) Dies ist netzwerkbezogen (meine Verbindung erfolgt über den HE6-Tunnel zum Ubunut 18.04-> LXD-Container). Mit einem Tunnel-Setup der gleiche Fehler wie oben. Mit anderen Tunneln funktioniert das Setup in Ordnung (ich vermute hier, aber dies ist wahrscheinlich eine Art MTU-Problem).

1. ANSIBLE_SSH_ARGS = "- o ControlMaster = no" hilft ein wenig - die Verbindung bleibt bei Verwendung bei einer anderen Aufgabe hängen.