<html style="direction: ltr;">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="UTF-8" bgcolor="#FFFFFF"
text="#000000">
<br>
<div class="moz-cite-prefix">On 11/12/2012 12:51 PM, Nadav Har'El
wrote:<br>
</div>
<blockquote
cite="mid:20121112105146.GA12342@fermat.math.technion.ac.il"
type="cite">
<pre wrap="">On Mon, Nov 12, 2012, Elazar Leibovich wrote about "Re: Is forbidding concurrent ssh sessions a good idea?":
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
Let me offer another completely different idea, without any kills and
similar tricks: End your ~/.profile with "screen -R -D"
What will this do?
The login shell will start screen(1), and let the admin work in it.
If another admin logs in, he doesn't just kill the existing session - he
also takes over the existing instance of "screen", and can see what the
other admin was in the middle of doing.</pre>
</blockquote>
+1 for screen, but maybe without the kill stuff. If there is a
screen session going on, spring-up a new user session with a MOD
notification, this way the admin can coordinate killing his
colleague or working simultaneously, if the job permits. <br>
<blockquote
cite="mid:20121112105146.GA12342@fermat.math.technion.ac.il"
type="cite">
<pre wrap="">
This "screen" will also allow the admin to have multiple screens - which
you prevent him from doing with several separate sshs, so he'll
appreciate "screen" anyway.
If you don't know screen(1), I suggest you learn it - it is an
absolutely wonderful tool.
</pre>
</blockquote>
<br>
</body>
</html>