Using GNU screen's multiuser feature for remote support
Posted by mikhailian on Wed 9 Jan 2008 at 09:04
It is often a waste of time for the person on the other end of the phone to listen to the support guy without really seeing what goes on. Using GNU screen two people can watch what is happening, and we'll show how here
One way to get the user involved is to let him follow on screen what you do.
So, log in and start screen on the command line. Then, enter ^A:multiuser on[RET]. That is, type Ctrl-a to enter the command mode, then type : to enter the screen's build-in command line. You can now activate the multiuser mode by entering multiuser on in the screen's command line that appears in reverse color at the bottom of the console window. To execute, hit Return.
The other guy just has to log in with the same user, type screen -x to connect to your screen session running in multiuser mode and follow what you do.
But there's a solution ! Just made /usr/bin/screen with the bit setuid (sudo chmod u+s /usr/bin/screen), and now, after activate the multiuser option, just add an acl like : ^Aacladd techguy[RET], then the user techguy can join your screen by typing : screen -rx yourusername/
And remember than root can always access a multiuser session !
(Note, this tip was already available at https://www.debian-administration.org/articles/34#comment_10 ;-))
[ Parent | Reply to this comment ]
http://debaday.debian.net/index.php?s=gems
Not the same but can be used in a similar manner.
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
By default, this is not allowed on Debian, even if you turn multiuser mode on, but if you absolutely need this functionality, you can do it this way (I just tested it---I, of course, don't use it this way):
First, make sure, as root:
1. Your /usr/bin/screen is setuid root. You can do this by running:
chmod u+s /usr/bin/screen
but this has quite a significant security implication, which is why this is not Debian's default setting.
2. Your /var/run/screen should have 755 permission (again, this is not Debian's setting (775 permission), as Debian lets setgid and group ownership of screen executable by utmp to handle writing to this system dir). You can do this by running:
chmod 755 /var/run/screen
Second, as the screen-sharing user (say, "debian"):
1. Run the "^A:multiuser on" command as described above.
2. Add the user to share it with (in this case, "test") by "^A:acladd test TMHNdoMbEaNfU". The last argument is the crypted password (you can generate one with mkpasswd, if necessary. If you were wondering, that's the crypt hash of "blah").
Now, as "test":
1. Run "screen -x debian/5321" where "5321" is the screen session ID (or you can type the first few digits that will uniquely match one screen session). You will be asked for password, type it, then now you have two users sharing a screen.
...
But, in my opinion, this is such a complicated setup, and unless you need the ACL features of screen (more detail at: http://aperiodic.net/screen/multiuser), the gaping hole that suid root of screen executable leaves is hardly worth it.
[ Parent | Reply to this comment ]
Onetime setup:
$ chmod u+s /usr/bin/screen
In the <hostuser> screen session:
:multiuser on
:acladd <guestuser>
From the <guestuser> a/c
$ screen -x <hostuser>/
[ Parent | Reply to this comment ]
$ chmod g-w /var/run/screen
SECURITY NOTE: By using the GNU screen multiuser feature, <hostuser> has, in effect, given <guestuser> a shell with all of <hostuser>'s privileges on the host machine. New windows in the screen session created by <guestuser> will be <hostuser> shells at the disposal of <guestuser>. This is bad for <hostuser> if <hostuser> does not, for instance, want <guestuser> to browse <hostuser>'s home directory.
Consider letting the <hostuser> be a dummy user with few privileges on the host machine, and then "acladd" the two users who wish to collaborate in the screen session.
[ Parent | Reply to this comment ]
[ Send Message ]
I turned logging on by connecting to screen session and during the session I could type in the root password for them to "su" to "root" where needed.
Obviously it's arguable how secure the whole thing was but the process was secure enough for what we were after.
Credits to Chris Wright who told me about the method.
- Hajir
[ Parent | Reply to this comment ]