SSH завис после неудачной передачи файла с помощью ansible

SSH завис после неудачной передачи файла с помощью ansible

У меня проблема с моим ssh-клиентом, который застрял во всей моей системе после неудачной передачи файла через Ansible. Я не думаю, что эта проблема связана с самим Ansible, потому что эффект распространяется на всю систему.

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

После этого проблема ssh появляется на любом хосте (даже хостах, не представленных в первом запуске playbook). Я предполагаю, что эта проблема на стороне клиента, поскольку она влияет на любое соединение на любом сервере ssh:

  • когда я подключаюсь по ssh в интерактивном режиме к хосту ( ssh <host>):нет проблем, это работает
  • когда я scp ( scp /tmp/a <host>:/tmp/): он застрял
  • когда я запускаю playbook: он зависаетGathering Facts
  • когда я запускаю команду через ssh ( ssh <host> ls /tmp/): она зависает

Журналы с ssh -v:

[thomas] ± ssh -v <host> /bin/ls /tmp/
OpenSSH_8.0p1, OpenSSL 1.1.1c  28 May 2019
debug1: Reading configuration data /***/.ssh/config
debug1: /***/.ssh/config line 34: Applying options for *.<FQDN>
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to <HOST>.<FQDN> [<IP>] port 22.
debug1: Connection established.
debug1: identity file /***/.ssh/<KEY> type 0
debug1: identity file /***/.ssh/<KEY>-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u2
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u2 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to <HOST>.<FQDN>:22 as '<USER>'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:NscFpuBFizN54BtNjWdhpLqmE3O1ngnN2lAxdEPxECs
debug1: Host '<HOST>.<FQDN>' is known and matches the ECDSA host key.
debug1: Found key in /***/.ssh/known_hosts:92
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /***/.ssh/<KEY> RSA SHA256:e1kfTBa1P5SorMk1Pd2DV+e8bIAnIsZosb/fC9I+l48 explicit agent
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /***/.ssh/<KEY> RSA SHA256:e1kfTBa1P5SorMk1Pd2DV+e8bIAnIsZosb/fC9I+l48 explicit agent
debug1: Server accepts key: /***/.ssh/<KEY> RSA SHA256:e1kfTBa1P5SorMk1Pd2DV+e8bIAnIsZosb/fC9I+l48 explicit agent
debug1: Authentication succeeded (publickey).
Authenticated to <HOST>.<FQDN> ([<IP>]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Sending command: /bin/ls /tmp/
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1

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

Единственный способ исправить это, который я нашел, — перезагрузить систему...

Дополнительная информация:

[thomas:~] $ uname -r
5.1.8-arch1-1-ARCH
[thomas:~] $ ssh -V
OpenSSH_8.0p1, OpenSSL 1.1.1c  28 May 2019

РЕДАКТИРОВАТЬ: через 2 часа проблема исчезла, но снова появилась, если копирование файла не удалось

Связанный контент