Die nicht interaktive SSH-Sitzung wird nicht beendet. Der SSH-Prozess wartet nach dem Beenden eines Skripts für immer

Wir führen ein einfaches Bereitstellungsskript remote mit einem Befehl wie aus ssh deployer@10.170.4.11 sudo /root/run-chef-client.sh. Es begann heute zu hängen , weil sshdwartete immer auf das 10.170.4.11auch nach sudobereits fertig war. Wir haben sshdim Debug-Modus begonnen und zwei verschiedene Arten von Protokollen erhalten. Das folgende Protokoll ist normal, wenn die Sitzung nicht hängt:

debug1: Received SIGCHLD.
debug1: session_by_pid: pid 23187
debug1: session_exit_message: session 0 channel 0 pid 23187
debug1: session_exit_message: release channel 0
Received disconnect from 10.170.4.6: 11: disconnected by user

Und wenn es hängt, bekommen wir folgendes:

debug1: Received SIGCHLD.
debug1: session_by_pid: pid 24209
debug1: session_exit_message: session 0 channel 0 pid 24209
debug1: session_exit_message: release channel 0

Unser Verständnis ist, dass der Serverprozess auf eine Kommunikation von einer Clientseite wartet und diese niemals erhält. Es ist schwer zu sagen, ob es sich um ein clientseitiges oder ein serverseitiges Problem handelt. Wir haben versucht, sshdunter zu laufen, straceaber es ist uns nicht gelungen, weil ein SUID-Bit in sudodiesem Fall ignoriert wurde. Was sollten wir also noch versuchen, diese Situationen zu debuggen / zu verhindern?

Die Verwendung ssh -t(erzwungene PTY-Zuweisung) auf einer Clientseite löste das Problem:

debug1: Received SIGCHLD.
debug1: session_by_pid: pid 31701
debug1: session_exit_message: session 0 channel 0 pid 31701
debug1: session_exit_message: release channel 0
debug1: session_pty_cleanup: session 0 release /dev/pts/1
Received disconnect from 127.0.0.1: 11: disconnected by user
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: PAM: deleting credentials

sshd wird von einem Pseudo-TTY gesteuert, nicht mehr von einem Client.