Ansible: ОШИБКА! Тайм-аут (12 с) ожидания запроса на повышение привилегий:

Ровно такая же проблема у меня: беспокоюсь:.

Версия Ansible: 2.0.0.2
Версия Python: 2.7.6
Среда: Ubuntu 14.04

У меня такая же проблема с:
Версия Ansible: 2.0.0.2
Среда: Ubuntu 14.04

Одна и та же. Столкновение с этим в самом начале на этапе настройки.
Версия Ansible: 2.0.0.2
Версия Python: 2.7.6
Среда: Ubuntu 14.04

В качестве примечания я переключил соединение на paramiko, и проблема исчезла, и playbook работал нормально. Кажется, проблема с реализацией OpenSSH по умолчанию.

Итак, для тех, у кого есть эта проблема, попробуйте использовать -c paramiko , пока они не исправят это.

обман # 14020

Сообщение об ошибке не то же самое, что и # 14020, и описываемые здесь обстоятельства гораздо шире. Но если вы скажете, что они такие же, спорить не буду.

это не совсем то же самое, что и на «ssh», а на другом, использующем «локальное» соединение, но я считаю, что они связаны с переписанным «обнаружением подсказок», тем не менее, это откроет заново.

Может ли кто-нибудь опубликовать отрывок из учебника, в котором возникает проблема (я понимаю, что это происходит непредсказуемо; я не прошу способа воспроизвести ее, просто какой-то контекст), а также вывод неудачного запуска с ANSIBLE_DEBUG=y и -vvvvv ?

У меня такая же проблема:
Ansible: 2.0.1.0-1ppa ~ точный
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:

Когда-то это срабатывало, но в большинстве случаев это было НЕ РАБОТАЕТ.

@nghnam Не могли бы вы вставить вывод неудачного запуска с установленным ANSIBLE_DEBUG = 1 в среде?

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

Привет, ребята, похожая ошибка здесь на v2.0.1.0 . -c paramiko предложенный @bbyhuy, работает каждый раз, но предложение @vutoff об отключении мультиплексирования в # 13278, я не боюсь. В любом случае, я думаю, что один из них должен быть отмечен как обман другого?

Вот журнал отладки ANSIBLE_DEBUG=y ansible all -m ping -vvvvv где возникает проблема: https://gist.github.com/oliver/e5a24a5b37c0006bb220

Это с Ansible 2.0.1.0-1ppa ~ точно в Ubuntu 12.04, при подключении к виртуальной машине Debian 8.2, работающей на локальном хосте (поэтому проблемы с сетью маловероятны). Я использую become=True и become_method=su и добавляю пароль root в файл hosts с помощью ansible_sudo_pass='pass' . Эта настройка отлично работала с Ansible 1.9.4-1ppa ~ точным.

Не уверен, должен ли этот отчет размещаться на # 14426 или # 13278, но поскольку эта ошибка, похоже, вообще не связана с with_items (это случается с любым простым playbook и даже с -m ping ), я опубликовал его Вот.

@oliver в вашем случае кажется несоответствием ожидаемому результату, Passwort: не сопоставляется с обработчиком приглашения su i18n.

@bcoca Хороший улов (и хороший аргумент против использования i18n на сервере)!
К сожалению, это все еще не работает, если я установил $ LANG в пустую строку и установил локаль по умолчанию в целевой системе на None. Я обновил Gist, и теперь он показывает подсказку «Пароль:», которая должна быть распознана, но по-прежнему приводит к таймауту.

Я считаю, что проблема связана с обработкой подсказок su (хотя в моих тестах это работает).

По-прежнему имеет ту же проблему (2.0.1.0), сообщение:

НЕ УДАЛОСЬ! => {"failed": true, "msg": "Тайм-аут (12 с), ожидание запроса на повышение привилегий:"}

Конфигурация моей игровой книги

• хосты: dev-сервер
  
  стать: да
  
  стать_пользователем: корень
  
  стать_метод: su
  
  * * * * * * * * * * * * * * * * * * * * *
  
  вывод -vvvvv

УСТАНОВИТЕ СОЕДИНЕНИЕ SSH ДЛЯ ПОЛЬЗОВАТЕЛЯ: ubuntu
SSH: ansible.cfg установить ssh_args: (-o) (ControlMaster = auto) (- o) (ControlPersist = 60s)
SSH: ANSIBLE_HOST_KEY_CHECKING / host_key_checking отключен: (-o) (StrictHostKeyChecking = no)
SSH: ansible_password / ansible_ssh_pass не установлен: (-o) (KbdInteractiveAuthentication = no) (- o) (PreferredAuthentication = gssapi-with-mic, gssapi-keyex, hostbased, publickey) (- o) (PasswordAuthentication = no)
SSH: ANSIBLE_REMOTE_USER / remote_user / ansible_user / user / -u set: (-o) (Пользователь = ubuntu)
SSH: ANSIBLE_TIMEOUT / тайм-аут установлен: (-o) (ConnectTimeout = 10)
SSH: набор PlayContext ssh_common_args: ()
SSH: набор PlayContext ssh_extra_args: ()
SSH: обнаружен только ControlPersist; добавлен 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 PreferredAuthentication = gssapi-with-mic, gssapi-keyex, hostbased, publickey-no PasswordAuthentication -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 установить ssh_args: (-o) (ControlMaster = auto) (- o) (ControlPersist = 60s)
SSH: ANSIBLE_HOST_KEY_CHECKING / host_key_checking отключен: (-o) (StrictHostKeyChecking = no)
SSH: ansible_password / ansible_ssh_pass не установлен: (-o) (KbdInteractiveAuthentication = no) (- o) (PreferredAuthentication = gssapi-with-mic, gssapi-keyex, hostbased, publickey) (- o) (PasswordAuthentication = no)
SSH: ANSIBLE_REMOTE_USER / remote_user / ansible_user / user / -u set: (-o) (Пользователь = ubuntu)
SSH: ANSIBLE_TIMEOUT / тайм-аут установлен: (-o) (ConnectTimeout = 10)
SSH: набор PlayContext ssh_common_args: ()
SSH: PlayContext установить sftp_extra_args: ()
SSH: обнаружен только ControlPersist; добавлен 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 PreferredAuthentication = 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]'
УСТАНОВИТЕ СОЕДИНЕНИЕ SSH ДЛЯ ПОЛЬЗОВАТЕЛЯ: ubuntu
SSH: ansible.cfg установить ssh_args: (-o) (ControlMaster = auto) (- o) (ControlPersist = 60s)
SSH: ANSIBLE_HOST_KEY_CHECKING / host_key_checking отключен: (-o) (StrictHostKeyChecking = no)
SSH: ansible_password / ansible_ssh_pass не установлен: (-o) (KbdInteractiveAuthentication = no) (- o) (PreferredAuthentication = gssapi-with-mic, gssapi-keyex, hostbased, publickey) (- o) (PasswordAuthentication = no)
SSH: ANSIBLE_REMOTE_USER / remote_user / ansible_user / user / -u set: (-o) (Пользователь = ubuntu)
SSH: ANSIBLE_TIMEOUT / тайм-аут установлен: (-o) (ConnectTimeout = 10)
SSH: набор PlayContext ssh_common_args: ()
SSH: набор PlayContext ssh_extra_args: ()
SSH: обнаружен только ControlPersist; добавлен 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 PreferredAuthentication = gssapi-with-mic, gssapi-keyex, hostbased, publickey-no PasswordAuthentication -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 СТАТЬ-УСПЕХ-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 / настройка; rm -rf "/home/ubuntu/.ansible/tmp/ansible-tmp-1459250484.21-51977895368027/"> / dev / null 2> & 1 '"'" '"" "" "" "" "" "" "" "'"' "'' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '" '' "'"' '

Если я использую sudo: да , все работает нормально.

Обнаружение этого при запуске фазы настройки на только что запущенном сервере Ubuntu 14.04 EC2.

Когда я второй раз запускаю автоматизацию на том же сервере, она работает нормально. Это происходит постоянно, когда я впервые запускаю автоматизацию Ansible на новом сервере.

Версия Ansible: 2.0.1.0
Версия Python: 2.7.6
Среда: Ubuntu 14.04

Я запускаю следующую команду:

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

см. следующую суть вывода: https://gist.github.com/Lowess/77442cf0533629e80b55faa7d6d91eb0

Могу я как-нибудь увеличить время ожидания в 12 секунд?

«Тайм-аут 12 секунд» - это настройка конфигурации timeout + 2 секунды (см. Ssh.py ).

Это не исправление, но установка timeout на 30 дала нам тайм-аут эскалации 32 секунды, которого до сих пор было достаточно (даже для наших более медленных экземпляров AWS EC2), чтобы обойти ошибку.

@somechris Я только что попробовал ваши настройки, и это сработало!

По какой-то причине фаза setup занимает около 20-25 секунд. Это первый раз, когда я сталкиваюсь с подобной проблемой при запуске Ansible против AWS. Я все еще думаю, что где-то есть проблема, потому что с Ansible V1 мне не нужно было увеличивать значение тайм-аута.

Еще раз спасибо!

Я подозреваю, что тайм-аут просто не работал должным образом в v1.

@amenonsen В таком случае для меня теперь все имеет смысл. Спасибо за точность.

Та же проблема.

Ansible Host: Ubuntu 14.04
Managed Hosts: CentOS 7.2

Обходной путь, описанный здесь , помог

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

Симптомы были точно такими же (вот системный журнал от хостов centos)

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 офигенно , вот исправил для меня!

authconfig --disablefingerprint --update

Есть ли на убнуту 14.04 аналогичная команда? С нами тоже

В ansible.cfg установите transport = paramiko в разделе [по умолчанию].

В ansible.cfg проблема с развертыванием 10+ серверов с использованием ansible 2.0.1.0 устранена следующим образом:

[defaults]
timeout = 30

Paramiko, похоже, не работает с моей конфигурацией бастиона, в то время как ssh работает как шарм (минус стать / стать_пользователем / стать_методом: su). Меня сильно укусила эта ошибка, могу ли я чем-нибудь помочь?

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

Мне тоже интересно, просто установка в 2.x медленнее. Мы очень часто наблюдаем таймауты установки при работе с 2.1, но никогда с 1.9. Мы увеличили таймаут до 30, но все же на 2.1 это случается довольно часто. (Увеличится больше, чтобы попытаться увидеть, действительно ли это тайм-аут или что-то, что никогда не завершится.)

К вашему сведению, мы не видели этой ошибки пару месяцев. Мы реализовали обходной путь от @szhem для наших хостов RHEL 6.7 и, по-видимому, исправили его. Для наших хостов RHEL 7.2 они используют более новую версию authconfig (версия 6.2.8-10), которая, по-видимому, решает эту проблему, потому что для них нам не нужен обходной путь.

Мы также используем RHEL 7.2 на наших подчиненных серверах Jenkins и серверах Tower.

Запуск 2.2 из источника с хостами CentOS 7.2 из Azure.

Как ни странно, некоторые служебные вызовы systemd заканчиваются таймаутом (12 с).

Я избавился от этой ошибки, добавив nopasswd моему пользователю в / etc / sudoers
username ALL=(ALL) NOPASSWD:ALL

должен быть в конце sudoers

@gandhar Я столкнулся с этой ошибкой, когда уже включил nopasswd. Похоже, это всего лишь одна из многих вещей, на которые расходуется время ожидания.

Вы пробовали отлаживать свой ssh-сервер на узлах? Сколько времени требуется ssh для входа в узел? Попробуйте добавить UseDNS no в файл /etc/ssh/sshd_config на узлах.

• 1
  Проблема возникает, когда я развертываю более 3 AWS EC2 одновременно.
  @somechris спасибо за работу, он отлично работает даже в режиме стратегия: бесплатный.

НЕ УДАЛОСЬ! => {"failed": true, "msg": "Тайм-аут (12 с) ожидания запроса повышения привилегий:"
ОС: CentOS Linux, выпуск 7.2.1511 (Core)
Ansible: анзибль 2.2.0

Для записи. Я вижу проблему с межсетевым экраном FreeBSD PF. Порт SSH открыт, и соединение SSH из командной строки работает нормально. Таймаут пропадает, когда я отключаю брандмауэр.

РЕШЕНИЕ

./lib/ansible/plugins/connection/ssh.py строка 403 (коммит 9fe430867063a0a63316e9bb71e9ba03a475a989):

из:

timeout = 2 + self._play_context.timeout

кому:

timeout = 30 + self._play_context.timeout

ОСНОВНАЯ ПРИЧИНА

Отложенные среды (общедоступные облака и т. Д.) Могут вызывать тайм-ауты из-за строгого тайм-аута по умолчанию. Пользователь должен иметь возможность настроить тайм-аут в соответствии со своими потребностями, но context.timeout не обновляется при редактировании ansible.cfg .

складывается в # 13278

та же проблема, добавление become_user: <username>
удалил ошибку

Столкнувшись с аналогичной проблемой, добавление -c paramiko в мою команду ansible-play помогло решить эту проблему.

Я запускаю ansible 2.1.1.0 и получаю эту ошибку. Единственный способ заставить его работать - это в моем сборнике пьес:

remote_user: david
sudo: yes

И добавляем в команду --ask-become-pass .

У новичка была эта проблема. Исправлено:

sudo:yes

Что заменило:

become: yes
become_user: root
become_method: su

Я почти уверен, что это моя собственная ошибка пользователя, но пока я использую устаревший метод.

Версия 2.0.0.2

Оказывается, я использовал неправильный метод get_method (su), это работает по умолчанию (sudo):

become: yes

Я всегда получаю эту ошибку, когда убиваю ansible (ctrl + c) и снова пытаюсь перезапустить игру. Добавление -c paramiko также решает проблему. Через некоторое время он возобновит нормальную работу, так что я предполагаю, что на сервере что-то должно выйти из строя ...
Однако это может быть другая проблема, потому что это всегда происходит в самом начале игры и никогда в случайное время во время игры.

Честно говоря, какой вообще смысл это менять? В ходе того, что выглядит как 2 незначительных исправления, практически все мои плейбуки сломаны. Помимо преобразования всего этого в поведение, ansible работал безупречно.

https://github.com/ansible/ansible/issues/14426#issuecomment -205938301 от @somechris предполагает, что тайм-аут влияет на тайм-ауты эскалации. Однако в связанной документации четко указано:

Это тайм-аут SSH по умолчанию, используемый при попытках подключения:

Если люди сообщают, что увеличение тайм-аута приводит к исчезновению ошибок с запросом на эскалацию, может показаться, что документация нарушена, или где-то есть еще одна более зловещая проблема.

@tsoikkel провел здесь анализ фактического кода:
https://github.com/ansible/ansible/issues/14426#issuecomment -245256330

Это говорит о том, что документация верна, но не говорит о том, почему изменение тайм-аута устраняет проблему эскалации .

Ссылка на фиксацию на самом деле не показывает соответствующий код, но здесь он находится в текущем мастере:

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

Является ли проблема эскалации тайм-аутом SSH, тайм-аутом выполнения команды или чем-то еще? Из этого обсуждения неясно, какова настоящая первопричина.

Вот конкретный код, связанный с ошибками запроса на эскалацию:

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

К сожалению, я недостаточно питон, чтобы понять, когда это произойдет. Возможно, кто-то сможет объяснить здесь поток, поскольку я не уверен, почему достижение значения timeout в этом конкретном случае может вызвать ошибку.

Увеличивая тайм-аут, мы скрываем настоящую причину сбоя ssh в первую очередь со значением повтора 12 секунд, которое все еще остается значительным.

Кто-нибудь знает, почему ansible не может так случайно подключиться к хосту? например, у нас есть 50 узлов в нашей настройке, управляемых с помощью ansible, и тайм-аут происходит в 3% случаев на полностью случайных узлах и случайных задачах, и если мы повторно запустим playbook во второй раз, все будет хорошо.

Привет,
извините за комментарий к закрытой заявке.
Мы столкнулись с той же проблемой с ansible 2.2.0 и 2.2.2, и нам удалось, что проблема появляется только с Python 3.5. В Python 2.7 вроде все нормально.

все еще есть проблема с этим

У меня такая проблема. Почему вопрос закрыт?

Я тоже это вижу. Это не исправлено и не должно быть закрыто.

Видя это в последнем ансибле. Почему это закрыто?

Я тоже это вижу в 2.3.0

Прокомментируйте проблему над своим комментарием. Модификации ответят, что это закрыто.

Мне нужно было удалить флаг -n , который вызывал проблему с sudo без пароля.
Как только я это сделал, эта ошибка начала возникать.
Согласно комментарию @davidmoshal , я изменил become: yes на become: root и моя проблема исчезла.

become: root неверен, он не устанавливает пользователя, но в итоге оказывается значением True для become так что это действительно без изменений.

Я могу подтвердить, что откат до ansible1.9 решает все мои странные проблемы с SSH-соединением. Я не знаю, что не так с ansible2.x, но я не буду в ближайшее время обновляться, так как это, похоже, продолжает сохраняться. Я видел комментарии о том, что это не ошибка, и я категорически не согласен. Единственная переменная, которую я изменил, - это доступное обновление. Я управляю более чем 70 серверами без проблем с ansible1.9, ansible 2.0 не работает с каждым экземпляром, который у меня есть. Это ненадежная ошибка. Ни ssh, ни какой-либо другой уровень.

Просто была эта проблема для меня, это происходило 4-5 раз подряд. Ansible 2.3, Ubuntu 16.04.1.
Но поскольку сегодня у меня не было никаких проблем в той области, где это начало происходить, и я не делал никаких изменений, я просто начал думать, что что-то идет не так с самим управляющим узлом.
Я решил перезапустить управляющий узел и попробовать еще раз, и это сработало для меня без проблем. Проблема ушла.

Также есть такая же проблема с 2.3.0.0 и 2.4.1.0 с конвейерной обработкой. Из-за неправильной конфигурации с нашей стороны конвейерная обработка была отключена случайно на некоторое время (не знаю, как долго, я подозреваю, что переключение до версии 2.0), но включение ее снова привело к таймауту запроса повышения привилегий, упомянутому здесь.

Я использую просто become = True и become_method = sudo . Единственная «особенная» вещь, которую я действительно делаю, - это установка ANSIBLE_SSH_ARGS чтобы она записывала UserKnownHostsFile в определенное произвольное место - но я сомневаюсь, что это на что-нибудь повлияет?

Я попытался переключиться на paramiko, но в моей тестовой установке произошел сбой и полностью сгорел, а увеличение таймаутов также не помогло, это не удалось как в моей тестовой настройке, так и в нашей производственной среде.

Настроить:

• Управляющая машина 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)

Случайно получить эту ошибку при тестировании плейбука, последний раз это было во время действия файла (папка уже существовала). У двух виртуальных машин один и тот же пользователь "vagrant", а у Solaris нет пароля root.

Я использовал --ask-стать-pass и нажал ENTER. Все-таки ошибка произошла ...

В моем случае это была настоящая проблема (а не ошибка) на моем сервере, где DNS не разрешался. Судо, очевидно, использует DNS для разрешения имени хоста машины, и если это не удается, время ожидания истекает. Я исправил это, исправив запись DNS в моем /etc/resolv.conf.

Эта проблема часто возникает в GCE с Ansible 2.5 от git. Пока что использование paramiko кажется жизнеспособным решением.

Мне пришлось killall ssh , возможно, устаревшее соединение ssh, если вы используете ControlPersist .

Привет, у меня такая же проблема с развертыванием на ubuntu 16.04 с ansible 2.4.2.0, параметр --paramiko решает проблему, но в том же случае не читайте мой ~ / .ssh / config, поэтому вместо параметра --paramiko я решаю отключение опции конвейерной обработки (по умолчанию False) в файле ansible.cfg добавить:

[ssh_connection]
pipelining = False

У меня возникла такая же проблема при попытке запустить playbook в контейнере LXD Ubuntu 16.04. Я мог бы использовать ssh в контейнере нормально, но для sudo su потребуется много времени, и это приведет к ошибке sudo: unable to resolve host ingest0: Connection timed out .

Я добавил имя хоста в /etc/hosts и проблема исчезла - я мог запустить playbook без тайм-аута при эскалации, и я мог немедленно sudo su .

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

Я использую ansible 2.4.3.0 и python 2.7.12 .

моя проблема была решена путем изменения файла hosts с

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

к

[sandbox]
ip

где ip - это ip-адрес машины.

Почему это закрыто?
Я только что установил новый сервер Ubuntu с последними версиями Ansible и Python, но ошибка все еще существует.
Ни один из обходных путей не работает.

Почему это закрыто?

Вероятно, потому что невозможно спросить каждого пользователя, работает ли решение (я). Между прочим, вероятно, есть несколько разных причин ошибки. Человек решил закрыть проблему.

Я согласен,

У меня такая же проблема, я дал пользователю sudoers root .... Я принудительно сменил пользователей.

Ничего не работает, и разумная ошибка требует расследования. Может быть, здесь требуется лучшая обработка исключений?

Моя playbook выглядит так:

• хосты: localhost

стать_пользователем: Дженкинс
gather_facts: правда
роли:
- {роль: bareos, теги: местные}

• хосты: dev-cluster
  удаленный_пользователь: centos
  gather_facts: правда
  роли:

  • {роль: bareos, теги: клиент}

• хосты: резервное копирование
  удаленный_пользователь: centos
  стать_пользователем: корень
  gather_facts: правда
  роли:

  • {роль: bareos, теги: сервер}

Все остальные хосты работают, но хосты: резервное копирование.

-vvv показывает

Использование файла модуля /usr/lib/python2.7/site-packages/ansible/modules/system/setup.py
УСТАНОВИТЕ СОЕДИНЕНИЕ SSH ДЛЯ ПОЛЬЗОВАТЕЛЯ: 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 PreferredAuthentication = 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 СТАТЬ-УСПЕХ-uywjmsrvdxhojzxfiqjygdwdsmbvvfzn; / usr / bin / python '"'" '"" "" "" "" "" "&& sleep 0'" '"' '

Север находится в AWS.
У меня есть в моей доступной команде

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

у меня просто есть эта проблема ， этот accur стал пользователем и копией модели. однако, когда я использую книгу прямого запуска root, это нормально.

сообщение об ошибке:

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 '"'" ''
фатальный: [192.168.202.105]: НЕ ВЫПОЛНЕНО! => {
"msg": "Тайм-аут (22 секунды) ожидания запроса повышения привилегий:"

Я согласен,

У меня такая же проблема, я дал пользователю sudoers root .... Я принудительно сменил пользователей.

Ничего не работает, и разумная ошибка требует расследования. Может быть, здесь требуется лучшая обработка исключений?

Моя playbook выглядит так:

• хосты: localhost

стать_пользователем: Дженкинс
gather_facts: правда
роли:

• {роль: bareos, теги: местные}

• хосты: dev-cluster
  удаленный_пользователь: centos
  gather_facts: правда
  роли:

  • {роль: bareos, теги: клиент}

• хосты: резервное копирование
  удаленный_пользователь: centos
  стать_пользователем: корень
  gather_facts: правда
  роли:

  • {роль: bareos, теги: сервер}

Все остальные хосты работают, но хосты: резервное копирование.

-vvv показывает

Использование файла модуля /usr/lib/python2.7/site-packages/ansible/modules/system/setup.py
УСТАНОВИТЕ СОЕДИНЕНИЕ SSH ДЛЯ ПОЛЬЗОВАТЕЛЯ: 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 PreferredAuthentication = 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 СТАТЬ-УСПЕХ-uywjmsrvdxhojzxfiqjygdwdsmbvvfzn; / usr / bin / python '"'" '"" "" "" "" "" "&& sleep 0'" '"' '

Север находится в AWS.
У меня есть в моей доступной команде

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

>

Моя проблема была связана с брандмауэром. Для меня это решено.

Для меня это было из-за плохого интернет-соединения.

У меня тоже возникает эта проблема:
Пособие:

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

Что дает ошибку:

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

В сборнике есть множество других задач, которые можно выполнить без проблем. Только этот с разными вариантами «стать» не работает.

Мои 3 цента:
Аналогичная проблема здесь. Та же ошибка. У меня не было времени на отладку, но я заметил:

1) Это связано с сетью (мое подключение через туннель HE6 к Ubunut 18.04-> LXD Containter). При настройке одного туннеля та же ошибка, что и выше. С другой настройкой туннеля все работает нормально (я предполагаю, но это, вероятно, какая-то проблема с MTU).

1. ANSIBLE_SSH_ARGS = "- o ControlMaster = no" немного помогает - соединение зависает на другой задаче при использовании.