The details of what would be broken in such an use case are unimportant. The important thing is that the proposed solution (a new ssh session kills the previous one) is brittle and one can never be sure no pathological use case would be missed and therefore mishandled.
And when a server is problematic, anything can happen, including the need to work on it using pathological use cases. My suggestion: configure things so that whenever a new ssh session is started, it'll check for existence of alive sessions. If there are alive sessions, it'll display a warning to the user and prompt him to continue or cancel. Also configure PROMPT_COMMAND (if you use bash) or equivalent (in other shells) so that before executing each interactive command the shell will check for other concurrent ssh connections and warn the user of any such alive connection. The basic idea is to assume that the concurrent ssh users are responsible adults and not try to prevent them from shooting their feet should they decide that the situation calls for this. --- Omer On Mon, 2012-11-12 at 12:35 +0200, Elazar Leibovich wrote: > On Mon, Nov 12, 2012 at 12:30 PM, Tzafrir Cohen > <tzaf...@cohens.org.il> wrote: > On Mon, Nov 12, 2012 at 10:05:02AM +0200, Elazar Leibovich > wrote: > > I'm considering to disallow concurrent ssh sessions on a > single-purpose > > production machine (say, DB server). > > > Sessions != shells. > > > Of course, what I care about is the shell, not the transport. > > This would have badly broken my personal use case. > > > While I can certainly see what's broken with it for using a regular > computer, whose stability I do not value much, and while there are > difficulties this may cause, do you see anything specific that will > break in the use case of a production server? -- Voting is almost never a way to reach consensus. Rather, it acknowledges that consensus has not been reached and side-steps further constructive attempts to reach it. Stefano Zacchiroli My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il