Ich habe ein Problem mit meinem SSH-Client, der nach einer fehlgeschlagenen Dateiübertragung über Ansible in meinem gesamten System festhängt. Ich glaube nicht, dass dieses Problem mit Ansible selbst zusammenhängt, da es sich auf das gesamte System auswirkt.
Das Problem tritt nach der Ausführung eines Ansible-Playbooks mit einem copyModul auf, das aus unbekanntem Grund fehlgeschlagen ist.
Danach tritt auf jedem Host ein SSH-Problem auf (sogar auf Hosts, die beim ersten Playbook-Lauf nicht vorhanden waren). Ich nehme an, dass dieses Problem auf der Clientseite liegt, da es jede Verbindung auf jedem SSH-Server betrifft:
- wenn ich interaktiv SSH auf dem Host (
ssh <host>) verwende:kein Problem, es funktioniert - wenn ich scp (
scp /tmp/a <host>:/tmp/) mache: es blieb hängen - wenn ich das Playbook ausführe: bleibt es hängen
Gathering Facts - wenn ich einen Befehl über ssh ( ) ausführe
ssh <host> ls /tmp/: bleibt er hängen
Protokolle mit 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
Ich habe es mit einem anderen Benutzer auf meinem System versucht: Das behebt das Problem nicht. Es ist kein Problem mit der Authentifizierung, es funktioniert, wenn ich nur das sshobige Protokoll verwende und es zeigt, dass die Authentifizierung funktioniert.
Die einzige Möglichkeit, das Problem zu beheben, die ich gefunden habe, ist ein Neustart meines Systems ...
Zusätzliche Information:
[thomas:~] $ uname -r
5.1.8-arch1-1-ARCH
[thomas:~] $ ssh -V
OpenSSH_8.0p1, OpenSSL 1.1.1c 28 May 2019
BEARBEITEN: Nach 2 Stunden ist das Problem verschwunden, tritt aber erneut auf, wenn das Kopieren der Datei fehlgeschlagen ist