Hello Darren,
The major problem we are running into is that the shell (both sh and ksh)
does not kill its child processes when there is no pty. The SSH patch
mentioned previously at
http://bugzilla.mindrot.org/show_bug.cgi?id=396
is not sufficient to kill the forced command completely.It will only kill
the shell script, but not any child processes the shell script runs. The
shell assumes the child is in the background (because there is no pty) and
therefore does not kill the child.
Consider a shell script /tmp/test.sh that in turn calls "sleep 1000".
If we
run a forced command
command="/tmp/test.sh",no-pty,no-port-forwarding ssh-rsa
it gives the following processes:
root 12724 1 0 04:46:13 ? 0:00 /opt/ssh/sbin/sshd
root 13309 12724 10 05:24:20 ? 0:00 sshd: root at notty
root 13313 13309 4 05:24:21 ? 0:00 /tmp/test.sh
root 13314 13313 2 05:24:21 ? 0:00 sleep 1000
When we disconnect the client, the sshd process is killed and the shell
script keeps running:
root 12724 1 0 04:46:13 ? 0:00 /opt/ssh/sbin/sshd
root 13313 1 0 05:24:21 ? 0:00 /tmp/test.sh
root 13314 13313 0 05:24:21 ? 0:00 sleep 1000
When we apply the patch to sshd, the sshd process sends a SIGHUP (hangup)
signal to /tmp/test.sh before exiting. The shell script (/tmp/test.sh) is
killed, but the shell
script does NOT kill its child sleep process. Here is the process list after
the client disconnects:
root 12724 1 0 04:46:13 ? 0:00 /opt/ssh/sbin/sshd
root 13314 1 0 05:24:21 ? 0:00 sleep 1000
You can test this by manually running the command:
# PID=`ps -ef | grep /tmp/test.sh | awk '{print $2}'`
# kill -HUP $PID
The shell script will be killed but the child process (sleep 1000) will keep
running.
Please let us know your comments on this.
Thanks in Advance,
Kumaresh.
----- Original Message -----
From: "Darren Tucker" <dtucker at zip.com.au>
To: "Kumaresh" <kumaresh_ind at gmx.net>
Cc: "OpenSSH Devel List" <openssh-unix-dev at mindrot.org>
Sent: Thursday, January 01, 2004 4:49 AM
Subject: Re: OpenSSH - forced command - no-pty issue
> You do not need to send bug reports directly to me, I read the list.
>
> Kumaresh wrote:
> > We have an issue where forced commands are left hanging on the sshd
server> > running whenever the ssh client disconnects.
> [snip]
> > Is there a way, which we can notify and kill the commands or child
> > processes when the sshd is terminated.?
>
> This sounds like bug #396. For details and patch see:
> http://bugzilla.mindrot.org/show_bug.cgi?id=396
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.561 / Virus Database: 353 - Release Date: 1/13/2004
Kumaresh wrote:> The major problem we are running into is that the shell (both sh and ksh) > does not kill its child processes when there is no pty. The SSH patch > mentioned previously at > http://bugzilla.mindrot.org/show_bug.cgi?id=396 > > is not sufficient to kill the forced command completely.It will only kill > the shell script, but not any child processes the shell script runs. The > shell assumes the child is in the background (because there is no pty) and > therefore does not kill the child.The script should catch the SIGHUP and clean up after itself.> Consider a shell script /tmp/test.sh that in turn calls "sleep 1000". If we > run a forced command > command="/tmp/test.sh",no-pty,no-port-forwarding ssh-rsa > it gives the following processes: > > root 12724 1 0 04:46:13 ? 0:00 /opt/ssh/sbin/sshd > root 13309 12724 10 05:24:20 ? 0:00 sshd: root at notty > root 13313 13309 4 05:24:21 ? 0:00 /tmp/test.sh > root 13314 13313 2 05:24:21 ? 0:00 sleep 1000 > > When we disconnect the client, the sshd process is killed and the shell > script keeps running: > > root 12724 1 0 04:46:13 ? 0:00 /opt/ssh/sbin/sshd > root 13313 1 0 05:24:21 ? 0:00 /tmp/test.sh > root 13314 13313 0 05:24:21 ? 0:00 sleep 1000 > > When we apply the patch to sshd, the sshd process sends a SIGHUP (hangup) > signal to /tmp/test.sh before exiting. The shell script (/tmp/test.sh) is > killed, but the shell > script does NOT kill its child sleep process. Here is the process list after > the client disconnects: > > root 12724 1 0 04:46:13 ? 0:00 /opt/ssh/sbin/sshd > root 13314 1 0 05:24:21 ? 0:00 sleep 1000 > > You can test this by manually running the command: > # PID=`ps -ef | grep /tmp/test.sh | awk '{print $2}'` > # kill -HUP $PID > > The shell script will be killed but the child process (sleep 1000) will keep > running.The shell (script) needs to deal with its own children, there's not much sshd can do (except possibly sending the HUP to the process group rather than the shell?) It seems similar to this bug: http://bugzilla.mindrot.org/show_bug.cgi?id=52 "Known-good workarounds: * bash: shopt huponexit on * tcsh: none * zsh: setopt HUP (usually the default setting) (taken from email from Jason Stone to openssh-unix-dev, 5 May 2001) * pdksh: ?" -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Circa 2004-01-20 12:11:10 +1100 dixit Darren Tucker:
: It seems similar to this bug:
: http://bugzilla.mindrot.org/show_bug.cgi?id=52
:
: "Known-good workarounds:
[...]
: * pdksh: ?"
pdksh: set +o nohup (as long as the shell is a login shell)
--
jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
.....................................................................
:"The methods now being used to merchandise the political candidate :
: as though he were a deodorant positively guarantee the electorate :
: against ever hearing the truth about anything." --Aldous Huxley :
:...................................................................:
Hello, Thanks for the pointers. Unfortunately, we do not have options such as "shopt ..." in Ksh or sh and we are using these shells on HP-UX. From our point of view, this is a security issue. A malicious user could cause a denial of service on the server by establishing many connections and breaking them, which would leave many shell processes/sub-processes running on the server and thus might eventually exhaust the kernel resources on the server. We have done some changes to the openssh source to fix this issue. The patch is attached with this mail and the diff is taken with OpenSSH-3.7.1p2 version. The basic change is, sending the HUP to the process group when the session is closed. There are two issues in this, the forced command may be a foreground process or a background process. So, the modification in session_close() function is such that, 1. If the child process has exited, no need to send any signal. 2. If the child process has not exited, then kill the process group using kill(-pid, SIGHUP). While the changes in session_close( ) works for HP-UX ssh clients, it is not working for the windows PuTTY ssh clients. So, that is corrected by calling session_destroy_all(NULL) in the process_input( ) function in serverloop.c, where the server gets terminated when the PuTTY client session is closed. BTW, rshd works in this way. The HUP signal is passed to the process group when we execute the remote commands. Please review the patch and let us know if this will be added to the next version. ViSolve OpenSSH Support support at visolve.com www.visolve.com ----- Original Message ----- From: "Darren Tucker" <dtucker at zip.com.au> To: "Kumaresh" <kumaresh_ind at gmx.net> Cc: <madhav_vaidy at yahoo.com>; "OpenSSH Devel List" <openssh-unix-dev at mindrot.org> Sent: Tuesday, January 20, 2004 6:41 AM Subject: Re: OpenSSH - forced command - no-pty issue> Kumaresh wrote: > > The major problem we are running into is that the shell (both sh andksh)> > does not kill its child processes when there is no pty. The SSH patch > > mentioned previously at > > http://bugzilla.mindrot.org/show_bug.cgi?id=396 > > > > is not sufficient to kill the forced command completely.It will onlykill> > the shell script, but not any child processes the shell script runs. The > > shell assumes the child is in the background (because there is no pty)and> > therefore does not kill the child. > > The script should catch the SIGHUP and clean up after itself. > > > Consider a shell script /tmp/test.sh that in turn calls "sleep 1000". Ifwe> > run a forced command > > command="/tmp/test.sh",no-pty,no-port-forwarding ssh-rsa > > it gives the following processes: > > > > root 12724 1 0 04:46:13 ? 0:00 /opt/ssh/sbin/sshd > > root 13309 12724 10 05:24:20 ? 0:00 sshd: root at notty > > root 13313 13309 4 05:24:21 ? 0:00 /tmp/test.sh > > root 13314 13313 2 05:24:21 ? 0:00 sleep 1000 > > > > When we disconnect the client, the sshd process is killed and the shell > > script keeps running: > > > > root 12724 1 0 04:46:13 ? 0:00 /opt/ssh/sbin/sshd > > root 13313 1 0 05:24:21 ? 0:00 /tmp/test.sh > > root 13314 13313 0 05:24:21 ? 0:00 sleep 1000 > > > > When we apply the patch to sshd, the sshd process sends a SIGHUP(hangup)> > signal to /tmp/test.sh before exiting. The shell script (/tmp/test.sh)is> > killed, but the shell > > script does NOT kill its child sleep process. Here is the process listafter> > the client disconnects: > > > > root 12724 1 0 04:46:13 ? 0:00 /opt/ssh/sbin/sshd > > root 13314 1 0 05:24:21 ? 0:00 sleep 1000 > > > > You can test this by manually running the command: > > # PID=`ps -ef | grep /tmp/test.sh | awk '{print $2}'` > > # kill -HUP $PID > > > > The shell script will be killed but the child process (sleep 1000) willkeep> > running. > > The shell (script) needs to deal with its own children, there's not much > sshd can do (except possibly sending the HUP to the process group rather > than the shell?) > > It seems similar to this bug: > http://bugzilla.mindrot.org/show_bug.cgi?id=52 > > "Known-good workarounds: > * bash: shopt huponexit on > * tcsh: none > * zsh: setopt HUP (usually the default setting) > (taken from email from Jason Stone to openssh-unix-dev, 5 > May 2001) > * pdksh: ?" > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.561 / Virus Database: 353 - Release Date: 1/13/2004