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