Thanks Rusty, Mark & Karl.
Well to be honest, i first wanted to solve this so that i could keep (me) from locking
myself out
of my box, which i did in a fit of stupidity awhile ago. So i wrote a simple script
that has been
doing the job, until a friend pointed out the issue that i just brought up. It seemed
like an
interesting problem, so i decided to persue it.
And the point is taken, that if someone could kill the sshd process that let him/her
in, then he
could also kill the watchdog that keeps it up.
I like the netstat -l solution, it's simple and it works. Another suggestion was to
try to telnet
to port 22 (or whatever port i have it running on) and check for a signature response.
Another way
would be to keep track of the PID that the orginal server had. Oh, another is to have
init/inittab
do the deed. A final one that i'll add is to start sshd with something like "daemon"
or another
such program that starts applications in daemon mode and makes sure they stay running.
Anyway, thanks again for your help. I will play it with a bit more, and in the
meantime i have
adjusted the logic (logistics) that let me lock myself out. Plus the simpleton
watchdog that works
well, except that it doesn't make that distinction between "server" and "doer".
Cheers,
j
--- Mark Rafn <[EMAIL PROTECTED]> wrote:
> On Fri, 20 Apr 2001, John Wolford wrote:
>
> > I have a question that might be off-topic for this list, but then
> > again maybe not.
>
> Probably mildly so. Comp.unix.programmer is a good spot for questions
> like this.
>
> > How can i tell if a given sshd process is serving
> > ssh? Other than trying to connect to it, that is.
>
> sshd is always serving ssh, in some sense. The main daemon is listening
> for new ssh connections, and the spawned daemons are servicing existing
> connections.
>
> It sounds like you're trying to make sure that there is an sshd actually
> listening, regardless of whether there are sshds servicing connections.
>
> > running on a box, and there is a script watching to make sure that
> > it's running. But if someone logs in via ssh, another sshd process
> > gets spawned for that connection. If that person were to somehow kill
> > the sshd server process (the parent of the spawned sshd) then s/he
> > could continue on with the connection but nobody else would be able to
> > get in. The watchdog would not know this because it would see a sshd
> > in the process list, which is all it is checking for. But i would like
>
> There are a number of ways to approach this.
>
> The first thing I usually think when anyone talks about a watchdog process
> is "why not use init"? For something this simple, a respawn entry in
> inittab may be all you need.
>
> If your watchdog script needs to do something more complicated than that
> (logging, e-mailing if something goes wrong, etc.), then you should
> basically do what init does - spawn sshd and wait() for it. You'll want
> to use something other than a shell script for this - perl, python, or C
> can all do this easily.
>
> If you're really stuck on pure shell scripting, you can either keep track
> of the listener-sshd's PID and check for that, or you can grep the output
> of netstat -l and make sure something is listening for ssh. There are
> probably other ways to check, but these seem easiest.
>
> Now on to the harder question. Why do you need to do this? Sshd is
> quite stable, and shouldn't need more of a watchdog than any other server.
> Are you experiencing problems with sshd dieing? If so, those should be
> tracked down and stomped. Users, of course, can't kill the listener
> process unless they're root, in which case they can kill the watchdog too.
> Generally, adding a layer of complexity without having a specific reason
> is likely to cause more problems than it solves.
> --
> Mark Rafn [EMAIL PROTECTED] <http://www.dagon.net/>
>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
