Silly SSH question

[invalid at pizzashack.org (Derek Martin)]

On Sat, Apr 02, 2005 at 02:10:13PM -0500, dsr at tao.merseine.nu wrote:
> On Sat, Apr 02, 2005 at 01:59:08PM -0500, Derek Martin wrote:
> > On Sat, Apr 02, 2005 at 01:36:31PM -0500, Josh Pollak wrote:
> > > The question is, how do I cleanly kill this tunnel? I've been running 
> > > 'ps aux | grep ssh', finding the line and killing it, but that seems 
> > > kludgy. Is there a 'right way' to do this? 
> > 
> > Yeah, you just named it. ;-)  Seriously... there isn't any other way.
> 
> You know better than to say things like that.

Well, you took what I said in a different light than that in which I
meant it...  I guess I'll have to give the long-winded, pedantic
version in order to avoid confusion.

> `netstat -ap |grep ssh` to show you the process id while
> identifying the TCP connections made.

Yup, there's lots of ways to get the pid.  While technically they're
different, practically speaking they aren't.  Any way you get it,
you're going to have to poke through the output of some command that
lists pids, choose the right one, and use a program such as kill to
kill it.  The keystrokes may be different, but the overall "way to do
this" is identical, regardless of which specific commands you choose,
and none can be said to be "cleaner" than any other.

More to the point, ssh provides no convenient way to identify this
process and kill it.  It does not log its pid in a file such as
/var/run/ssh.pid, like many daemons do (ssh is acting as a daemon in
this role); it doesn't leave any pipes with well-known names open for
the purpose of sending it commands, like named does (or did -- now it
uses rndc); it doesn't set any environment variables to make it
easy to kill this connection.  All of these methods can't work,
because you could have any number of such processes in play
simultaneously, each owned by a different user, or all owned by the
same user.  Subsequent port forwarding connections would wipe out the
information left behind by previous ones.  None of these methods allow
a user any easy way to select the right process and kill it.  

Therefore, the basic metodology is, and can only be: 1. Use some
program to find out what the pid is.  2.  send a signal to that pid.
Any of the practical variations you come up with will fit this pattern.
Other impractical solutions do exist, including shutting down the
machine, etc.  I don't think we really need to discuss why those
aren't any "cleaner" than the originally proposed method...  At least
I hope not!  =8^)

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20050402/327d6ae1/attachment.sig>