Re: Is forbidding concurrent ssh sessions a good idea?
2012/11/12 Yedidyah Bar-David linux...@didi.bardavid.org: On Mon, Nov 12, 2012 at 06:32:25PM +0200, E.S. Rosenberg wrote: +1 for tmux, this does however imply that all the admins are using the same account to login (bad scenario) with or instead the tmux/screen line should be added at the end of /root/.profile and not ~/.profile IIRC screen, perhaps tmux too, has some rather complex set of permissions management options, which I would not be surprized if it turns out that actually do allow sharing a session from two different users. I did not try this. I su to the person's user if I want to share a session. Note that (by default?) you need to chown your tty to the other user or screen won't work. Just note that tmux inside of tmux or screen inside of screen tend to behave bad/not work, screen inside of tmux works, I never tried the other way around. Never had problems with screen inside screen. Actually, my everyday work environment comprizes of 3-level screens, some of which also have tmux inside them. I use different key combinations to travel around and it works very well. IIRC I did have to change a few configuration options when moving it from RedHat/CentOS to Debian, but other than that, it worked more-or-less error-free for something like 5 years now. Tell me if you want my configuration. It's not very elaborate, only does what it's meant to do - if you google for things like screenrc you'll find many examples of what people do with it. Oh sorry I meant by default, if you take the time to modify the key-bindings of the screen/tmux you want to nest then you should be fine. Regards, Eliyahu - אליהו -- Didi ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
2012/11/12 Yedidyah Bar-David linux...@didi.bardavid.org: On Mon, Nov 12, 2012 at 12:51:46PM +0200, Nadav Har'El wrote: On Mon, Nov 12, 2012, Elazar Leibovich wrote about Re: Is forbidding concurrent ssh sessions a good idea?: 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? 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. 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. ...and also look at its '-x' option which will allow sharing a session from two (or more) connections. This way your two admins will be able to talk over the phone while solving a problem together and not having to tell each other what they did and what happened. And while at it, also have a look at tmux, which is a screen replacement. +1 for tmux, this does however imply that all the admins are using the same account to login (bad scenario) with or instead the tmux/screen line should be added at the end of /root/.profile and not ~/.profile Just note that tmux inside of tmux or screen inside of screen tend to behave bad/not work, screen inside of tmux works, I never tried the other way around. Regards, Eliyahu - אליהו -- Didi ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On Mon, Nov 12, 2012 at 10:05 AM, Elazar Leibovich elaz...@gmail.com wrote: I'm considering to disallow concurrent ssh sessions on a single-purpose production machine (say, DB server). I thought of replacing the default shell with a shell that keeps its pid file in a central place. If such a file already exist, it'll kill the other running shell before logging in. Can't you use MaxSessions and/or MaxStartups in sshd config for this? Whatever you do, make sure sshd kills sessions after some appropriate timeout, otherwise you may find yourself in trouble... ;-) -- Oleg Goldshmidt | p...@goldshmidt.org ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On Mon, Nov 12, 2012 at 10:27 AM, Oleg Goldshmidt p...@goldshmidt.orgwrote: On Mon, Nov 12, 2012 at 10:05 AM, Elazar Leibovich elaz...@gmail.com wrote: I'm considering to disallow concurrent ssh sessions on a single-purpose production machine (say, DB server). I thought of replacing the default shell with a shell that keeps its pid file in a central place. If such a file already exist, it'll kill the other running shell before logging in. Can't you use MaxSessions and/or MaxStartups in sshd config for this? This options, as far as I can tell, drops new connections. I don't want to have a locked server, so I always allow new sessions to kill old ones. But never run concurrently. (There's a slight issue of scp not working, but this can be taken care of, by less privilleged user which is allowed in, just for rsync/files) Whatever you do, make sure sshd kills sessions after some appropriate timeout, otherwise you may find yourself in trouble... ;-) No problem with my scheme, if sshd won't kill old sessions, new sessions will... (or maybe I misunderstand you). -- Oleg Goldshmidt | p...@goldshmidt.org ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On Mon, Nov 12, 2012 at 10:40 AM, Elazar Leibovich elaz...@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? Also, there does not seem to be any warning to the already logged in user. Or any information. How will he know that he was knocked out and it was not a connection problem? If he thinks that he may try to log back in... Consider writing something to his terminal and giving him enough time and information to call the other guy? Yes, it's much more involved than kill -9... -- Oleg Goldshmidt | p...@goldshmidt.org ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On Mon, Nov 12, 2012 at 10:54 AM, Oleg Goldshmidt p...@goldshmidt.orgwrote: On Mon, Nov 12, 2012 at 10:40 AM, Elazar Leibovich elaz...@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. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
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. SSH can be used for various things (ssh, scp, whatever). I normally keep at least one active shell session and occasionally use minor ones for tab completion (of scp and such. Check out /etc/bash_completion/ssh ). In order to avoid the overhead of several SSH connections, I use a socket so that the various commands will use a single TCP connection and SSH session (the one of my main shell session). I also occasionally use ssh as, well a (secure) Remote SHell, and use it to execute command on the remote machine. I thought of replacing the default shell with a shell that keeps its pid file in a central place. If such a file already exist, it'll kill the other running shell before logging in. This would have badly broken my personal use case. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On Mon, Nov 12, 2012 at 12:30 PM, Tzafrir Cohen tzaf...@cohens.org.ilwrote: 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? ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On Mon, Nov 12, 2012, Elazar Leibovich wrote about Re: Is forbidding concurrent ssh sessions a good idea?: 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? 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. 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. -- Nadav Har'El| Monday, Nov 12 2012, 27 Heshvan 5773 n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |The average person thinks he isn't. - http://nadav.harel.org.il |Father Larry Lorenzoni ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On Mon, Nov 12, 2012 at 12:51:46PM +0200, Nadav Har'El wrote: On Mon, Nov 12, 2012, Elazar Leibovich wrote about Re: Is forbidding concurrent ssh sessions a good idea?: 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? 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. 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. ...and also look at its '-x' option which will allow sharing a session from two (or more) connections. This way your two admins will be able to talk over the phone while solving a problem together and not having to tell each other what they did and what happened. And while at it, also have a look at tmux, which is a screen replacement. -- Didi ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On Mon, 12 Nov 2012 12:51:46 +0200 Nadav Har'El n...@math.technion.ac.il wrote: On Mon, Nov 12, 2012, Elazar Leibovich wrote about Re: Is forbidding concurrent ssh sessions a good idea?: 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? 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. 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. There's now a (better, in my opinion) and also open-source (BSD-licensed) alternative to screen called tmux. See my earlier post about it to the linux-elitists mailing list (and the replies): http://zgp.org/pipermail/linux-elitists/2011-February/013288.html tmux is one of the first things I install on any new Linux system deployment (as well as htop and other stuff). I have barely scratched the surface of tmux (or GNU screen for that matter) but I find that from what I know it works much nicer. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ My Public Domain Photos - http://www.flickr.com/photos/shlomif/ Writing a BitKeeper replacement is probably easier at this point than getting its license changed. — Matt Mackall (who ended up writing a BitKeeper replacement) Please reply to list if it's a mailing list post - http://shlom.in/reply . ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On 11/12/2012 12:51 PM, Nadav Har'El wrote: On Mon, Nov 12, 2012, Elazar Leibovich wrote about "Re: Is forbidding concurrent ssh sessions a good idea?": 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? 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. +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. 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. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On Mon, Nov 12, 2012 at 12:51:46PM +0200, Nadav Har'El wrote: 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. 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. A version or two of Ubuntu had such a setup as th default, IIRC. They made the extra stuff added on top of screen in a separate package called byobu. It still seems to be under active maintinance. Under Debian and Ubuntu just install that package. I figure the scriptology there may provide useful inspiration on other distributions as well: https://launchpad.net/byobu -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
2012/11/12 Yedidyah Bar-David linux...@didi.bardavid.org: On Mon, Nov 12, 2012 at 12:51:46PM +0200, Nadav Har'El wrote: On Mon, Nov 12, 2012, Elazar Leibovich wrote about Re: Is forbidding concurrent ssh sessions a good idea?: 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? 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. 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. ...and also look at its '-x' option which will allow sharing a session from two (or more) connections. This way your two admins will be able to talk over the phone while solving a problem together and not having to tell each other what they did and what happened. And while at it, also have a look at tmux, which is a screen replacement. +1 for tmux, this does however imply that all the admins are using the same account to login (bad scenario) with or instead the tmux/screen line should be added at the end of /root/.profile and not ~/.profile Just note that tmux inside of tmux or screen inside of screen tend to behave bad/not work, screen inside of tmux works, I never tried the other way around. Regards, Eliyahu - אליהו -- Didi ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On 11/12/2012 10:05 AM, Elazar Leibovich wrote: I'm considering to disallow concurrent ssh sessions on a single-purpose production machine (say, DB server). You shouldn't... I'd just add 'who' to the end of the .profile / .bashrc / whatever and echo some warning. # I thought of replacing the default shell with a shell that keeps its pid file in a central place. If such a file already exist, it'll kill the other running shell before logging in. Something like export LOCKFILE=/tmp/singleshell.pid while [ "$(cat $LOCKFILE)" -eq "$LOCKFILE" ]; do kill $(cat "$LOCKFILE") sleep 1 kill -9 $(cat "$LOCKFILE") echo $PID $LOCKFILE done exec /bin/sh The benefits of that are, making sure it is always one man fixing the server (what can happen is two people get a call "help, server is not working", and forgetting to check who else is logged in in the rush). And, the option of streamline logging. I'll use sudosh2 or some similar recording shell/recording terminal, and I'll have the exact log of what happened, no need to correlate events in two shells. I'd like to hear your opinion and/orexperiencewith such a scheme. Thanks ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On Mon, Nov 12, 2012 at 8:33 PM, Dotan Shavit do...@shavitos.com wrote: On 11/12/2012 10:05 AM, Elazar Leibovich wrote: I'm considering to disallow concurrent ssh sessions on a single-purpose production machine (say, DB server). You shouldn't... I'd just add 'who' to the end of the .profile / .bashrc / whatever and echo some warning. It'd be much more beneficial for everyone, if in addition to a yes/no answer, you'll provide reasoning (for instance, what mischief can happen). I'm not much of a fan of warnings. We have a MOTD which says roughly This is a production server, beware of changing it, which is largely ignored. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On Mon, Nov 12, 2012 at 06:32:25PM +0200, E.S. Rosenberg wrote: +1 for tmux, this does however imply that all the admins are using the same account to login (bad scenario) with or instead the tmux/screen line should be added at the end of /root/.profile and not ~/.profile IIRC screen, perhaps tmux too, has some rather complex set of permissions management options, which I would not be surprized if it turns out that actually do allow sharing a session from two different users. I did not try this. I su to the person's user if I want to share a session. Note that (by default?) you need to chown your tty to the other user or screen won't work. Just note that tmux inside of tmux or screen inside of screen tend to behave bad/not work, screen inside of tmux works, I never tried the other way around. Never had problems with screen inside screen. Actually, my everyday work environment comprizes of 3-level screens, some of which also have tmux inside them. I use different key combinations to travel around and it works very well. IIRC I did have to change a few configuration options when moving it from RedHat/CentOS to Debian, but other than that, it worked more-or-less error-free for something like 5 years now. Tell me if you want my configuration. It's not very elaborate, only does what it's meant to do - if you google for things like screenrc you'll find many examples of what people do with it. -- Didi ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
2012/11/12 Yedidyah Bar-David linux...@didi.bardavid.org: On Mon, Nov 12, 2012 at 06:32:25PM +0200, E.S. Rosenberg wrote: +1 for tmux, this does however imply that all the admins are using the same account to login (bad scenario) with or instead the tmux/screen line should be added at the end of /root/.profile and not ~/.profile IIRC screen, perhaps tmux too, has some rather complex set of permissions management options, which I would not be surprized if it turns out that actually do allow sharing a session from two different users. I did not try this. I su to the person's user if I want to share a session. Note that (by default?) you need to chown your tty to the other user or screen won't work. Just note that tmux inside of tmux or screen inside of screen tend to behave bad/not work, screen inside of tmux works, I never tried the other way around. Never had problems with screen inside screen. Actually, my everyday work environment comprizes of 3-level screens, some of which also have tmux inside them. I use different key combinations to travel around and it works very well. IIRC I did have to change a few configuration options when moving it from RedHat/CentOS to Debian, but other than that, it worked more-or-less error-free for something like 5 years now. Tell me if you want my configuration. It's not very elaborate, only does what it's meant to do - if you google for things like screenrc you'll find many examples of what people do with it. Oh sorry I meant by default, if you take the time to modify the key-bindings of the screen/tmux you want to nest then you should be fine. Regards, Eliyahu - אליהו -- Didi ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Is forbidding concurrent ssh sessions a good idea?
On 11/12/2012 09:05 PM, Elazar Leibovich wrote: On Mon, Nov 12, 2012 at 8:33 PM, Dotan Shavit do...@shavitos.com wrote: On 11/12/2012 10:05 AM, Elazar Leibovich wrote: I'm considering to disallow concurrent ssh sessions on a single-purpose production machine (say, DB server). You shouldn't... I'd just add 'who' to the end of the .profile / .bashrc / whatever and echo some warning. It'd be much more beneficial for everyone, if in addition to a yes/no answer, you'll provide reasoning (for instance, what mischief can happen). Just saying 'kill' is indeed a nice tool, but 'talk' may also come in handy. # ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
