Package: ssh Version: OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004 Version: OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
This to me seems like a bug, but I am just a simple guy with limited mental capacity. (Using certificate authentication) ssh -t 10.44.12.2 hostname Hangs the client, defuncts the "hostname" command on the server ssh -t 10.44.12.2 "sleep 0.00000000000000000000000001;hostname" Works as expected, returns hostname of server. The two machines are on an internal network. The client is an old machine (800 Mhz) and the server is an Opteron 2 Ghz machine. Both are running debian. SSH versions are: client: OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3, SSH protocols 1.5/2.0, OpenSSL 0x0090603f server: OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004 I am aware of some problems with <defunct> processes because sshd waits for the return of an executed command, and sometimes that does not happen. This is why I am using the -t option. However, this issue seems to be related to timing (I was glad to have found a workaround using "sleep" - even a really tiny sleep time seems to solve the problem). I also tried "force-command" in the authorized_keys file, but the same happens. Finally, some debug outputs: Server, in extremely rare occasion that it DOES work, without SLEEP command (it works maybe 1 in a hundred times): May 6 09:22:28 backup sshd[11135]: debug1: session_close: session 0 pid 11136 May 6 09:22:28 backup sshd[11133]: debug1: session_by_tty: session 0 tty /dev/pts/6 May 6 09:22:28 backup sshd[11133]: debug1: session_pty_cleanup: session 0 release /dev/pts/6 May 6 09:22:28 backup sshd[11135]: debug1: channel 0: free: server-session, nchannels 1 May 6 09:22:28 backup sshd[11135]: Connection closed by ::ffff:10.44.12.3 May 6 09:22:28 backup sshd[11135]: debug1: do_cleanup May 6 09:22:28 backup sshd[11135]: debug1: PAM: cleanup May 6 09:22:28 backup sshd[11135]: (pam_unix) session closed for user backer-upper May 6 09:22:28 backup sshd[11135]: Closing connection to ::ffff:10.44.12.3 May 6 09:22:28 backup sshd[11135]: debug1: PAM: cleanup And when it doesn't work: May 6 09:23:57 backup sshd[11150]: debug1: session_input_channel_req: session 0 req pty-req May 6 09:23:57 backup sshd[11150]: debug1: Allocating pty. May 6 09:23:57 backup sshd[11148]: debug1: session_new: init May 6 09:23:57 backup sshd[11148]: debug1: session_new: session 0 May 6 09:23:57 backup sshd[11150]: debug1: session_pty_req: session 0 alloc /dev/pts/6 May 6 09:23:57 backup sshd[11150]: debug1: server_input_channel_req: channel 0 request exec reply 0 May 6 09:23:57 backup sshd[11150]: debug1: session_by_channel: session 0 channel 0 May 6 09:23:57 backup sshd[11150]: debug1: session_input_channel_req: session 0 req exec May 6 09:23:57 backup sshd[11150]: debug1: PAM: setting PAM_TTY to "/dev/pts/6" May 6 09:23:57 backup sshd[11151]: debug1: Setting controlling tty using TIOCSCTTY. <client hangs here> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
