SSH stuck after a failed file transfert with ansible

0

I have an issue with my ssh client which is stuck in my whole system after a failed file transfert through Ansible. I don't think that this issue is related to Ansible itslef, because the effect is on entire system.

Issue appears after a run of an ansible playbook with a copy module which failed for unknow reason.

After that, an ssh issue appear on any host (even hosts not present in first playbook run). I suppose that this issue in on client side because it affect any connection on any ssh server:

  • when I ssh interactively on host (ssh <host>): no issue, it works
  • when I scp (scp /tmp/a <host>:/tmp/): it stuck
  • when I run playbook: it stuck on Gathering Facts
  • when I run a command through ssh (ssh <host> ls /tmp/): it stuck

Logs with 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: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com 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 no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending command: /bin/ls /tmp/
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1

I have tried with a different user on my system: it doesn't fix it. It's not a issue related authentication, it work when I only usessh and log above shows that authentication works.

The only way that I found to fix it is to reboot my system...

Additional info:

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

EDIT: after 2 hours, the issue disappeared, but reappear if file copy failed

Thomas B

Posted 2019-06-26T10:03:46.893

Reputation: 1

What happens if you first SSH interactively, then run a nested shell in non-interactive mode ($SHELL -c "ls -l" or $SHELL -x -c "ls -l")? – user1686 – 2019-06-26T10:41:53.377

It works perfectly – Thomas B – 2019-06-26T11:35:50.503

No answers