Hi, On Sun, 16 Sep 2007 22:25:07 +0200 Alexander Skwar <[EMAIL PROTECTED]> wrote:
> A "/etc/init.d/sshd stop" won't kill any SSH sessions. It'll > simply the sshd "master process". Because of that, additional > logins won't be possible. An /etc/init.d/sshd stop/restart can very well fail. Depending on in what state this happens, it might stop accepting connections. Typical conditions might be that relevant changes on-disk occurred, e.g. PAM libraries, libc or similar libs that might dl() things. OTOH, if signal handling is broken, the KILL might traverse to the connection handling forked child. And that's enough to kick you out. So I would definately prefer to always have a guaranteed working sshd running (I find OpenVPN/telnet a bit strange and an unnecessary potential security hole). Your absolutely right in that restarting immediately or delayed after logging out of all sessions doesn't matter at all. But it's wrong that it *can't* occur that you kill your current session as well. So the delay doesn't make any specific sense here. It might reduce the risk of a zombie master process of sshd, but I don't see much evidence. OTOH, you lose the possibility of fixing restart problems within the running session. So you have to weight the risks. The real problem, however, can only be overcome by another way to login. Firing up another instance of sshd (on a different port) is just a matter of one simple command, so I definately prefer that. -hwh -- [EMAIL PROTECTED] mailing list
