Is forbidding concurrent ssh sessions a good idea?

[Elazar Leibovich]

On Mon, Nov 12, 2012 at 10:54 AM, Oleg Goldshmidt <pub at goldshmidt.org>wrote:

> On Mon, Nov 12, 2012 at 10:40 AM, Elazar Leibovich <elazarl at gmail.com>
> wrote:
>
> > No problem with my scheme, if sshd won't kill old sessions, new sessions
> > will... (or maybe I misunderstand you).
>
> No, I misunderstood you... Sorry.
>
> Killing existing active sessions in mid-flight seems hairy. You want
> to prevent two admins from tweaking the server simultaneously, and the
> latecomer may kill the session of the one who is already working,
> maybe in the middle of editing a configuration file, moving a bunch of
> data, whatever? Is it possible to leave a server in an
> unknown/inconsistent state?
>

Of course, the user should be notified beforehand and decide if he indeed
want to kill other session, the killed user should also get a notification
on his terminal. (it was just a draft, it's probably not even working, I
didn't run it). Joe will see that Moe has a session, and will ask him what
he's doing. But he'll never be able to log in simultaneously.

Yeah, that policy might force a kill -9 in some rare state (someone left an
active session and was sick, now we have to log in and kill his session).
But in the long run I think it'll prevent more problems. Hey, this session
might have something to do with what you're working on, so if you don't
kill it, you might also end up in an inconsistent state.

Moreover, you should probably look at at the log before killing this
session, and make sure you understand what he was doing. Understanding that
from a concurrent log, is a much more difficult job. Enforcing the rule of
one-session-at-a-time have benefit in this area as well.

You could accomplish that with a read-only user which can log in
concurrently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20121112/cbd0239b/attachment.html>