Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: ssh SIGHUP behavior with remote commands |
|---|---|
| Date: | Tue, 18 Jul 2006 21:34:22 -0700 (PDT) |
On Mon, 17 Jul 2006, Ryan Olf wrote:
I use ssh (OpenSSH_4.3p2, OpenSSL 0.9.7j on Gentoo Linux kernel 2.6.15) to run a command on a remote machine (same version) that doesn't terminate without an explicit kill. Is it possible to send this signal through ssh without using a login shell? Ideally, I'd be able to run "ssh server command," and then send SIGHUP to to the ssh process, which would result in it sending some signal to the command. However, the current behavior is that command is left running while ssh terminates. Alternatively, is it possible to tell ssh to send a signal to a command it is running on a remote server? I searched google and saw that there has been some discussion of similar issues in the past, but am not clear how/if it was resolved. Thanks a lot for the help,
I can give you some vague answers, centered around "you can't".
I investigated OpenSSH's sshd a while back (maybe 4.1 or late 3.x) and
it had no logic for dealing with signals it received via the SSH protocol.
Too bad. I did some work on adding that code, but didn't finish it.
We produce an SSH client for Windows. My goal was to be able to send
signals, especially a SIGHUP that could act as a "conditional
termination", instead of blindly quitting the client side. If the client
sent SIGHUP, and the host software was at a point where it could quit
cleanly, it would respond to the signal by logging out. OTOH, if it was in
a critical point, it could block that signal and not respond to it.
Properly executed, this combination could prevent orphan processes and
corrupted databases.
I'd be interested in hearing from anyone who has done similar work.
Regards,
....Bob Rasmussen, President, Rasmussen Software, Inc.
personal e-mail: ras@anzio.com
company e-mail: rsi@anzio.com
voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
fax: (US) 503-624-0760
web: http://www.anzio.com
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | ssh SIGHUP behavior with remote commands, Ryan Olf |
|---|---|
| Next by Date: | SCP hangs wile coying large files, Kevin Armstrong |
| Previous by Thread: | ssh SIGHUP behavior with remote commands, Ryan Olf |
| Next by Thread: | SCP hangs wile coying large files, Kevin Armstrong |
| Indexes: | [Date] [Thread] [Top] [All Lists] |