Home > System Administrator's Guide > Using screen for remote interaction

Using screen for remote interaction

November 12th, 2009

Basically, screen allows you to create virtual terminals which are not connected to your actual xterms or console screens. You can then disconnect from a screen session and reconnect from somewhere else while preserving your shell or other running processes.

 
This is just the beginning of screen’s power and flexibility. You can connect to a session more than once using the -x argument to screen. That means you can for example leave your mail program running in a terminal (under screen) at work and then connect from home to read your mail in the same process. There’s no need to disconnect at work, and when you come back in the next morning your mailer will be exactly as you left it, with all your state perfectly preserved.
Screen takes this feature, which is called multi-display mode, to the next level with multi-user mode. In multi-user mode more than one user can access and control a screen session. The problem with this mode is that it’s not obvious how to set it up. Here’s what I ultimately figured out with the help of some Google searching:
 
  1. Set the screen binary (/usr/bin/screen) setuid root. By default, screen is installed with the setuid bit turned off, as this is a potential security hole.
  2. The teacher starts screen in a local xterm, for example via screen -S SessionName. The -S switch gives the session a name, which makes multiple screen sessions easier to manage.
  3. The student uses SSH to connect to the teacher’s computer.
  4. The teacher then has to allow multiuser access in the screen session via the command Ctrl-a :multiuser on (all screen commands start with the screen escape sequence, Ctrl-a).
  5. Next the teacher grants permission to the student user to access the screen session with Ctrl-a :acladd student where student is the student login ID.
  6. The student can now connect to the teacher’s screen session. The syntax to connect to another user’s screen session is screen -x username/session.
At this point the teacher and student both have control of the session. Note that there are security implications to this — the student is operating the session as the teacher and could potentially do something to damage the system. If you don’t trust your students then you should probably use a special teacher account and not your normal login account. The teacher can also make the student’s session read-only. To do this, use the aclchg screen command to remove write access for the student: Ctrl-a :aclchg student -w "#". The student can then only observe the teacher’s actions. Otherwise, the teacher will have to let the student work on the honor system.
While my example centers on one teacher and one student, many users could attach to one session. There could even be multiple teachers and students.
What about communication between teacher and student? Well, we used a telephone, but you could use instant messaging, IRC, or VoIP for asking questions. There is also an message feature in multiuser screen: Ctrl-a :wall message will write a message to all users connected to a screen session. One problem with this is that it uses the terminal status line. In an xterm this is the window titlebar area, which, depending on your window manager, may not be very obvious.
The final ingredient for using screen as a teaching tool is logging. With a log of all the terminal output, my coworker and I would have an exact transcript of what we did in case there were any questions later. As I mentioned earlier, the standard Unix tool script is the obvious answer, but it is a very limited tool and does not produce very readable output. You also can’t turn it on and off inside a session if for example you want to run a full-screen tool such as a text editor.
Fortunately screen comes with a comprehensive logging facility that is much more sophisticated than what script can do. Screen’s logging can be turned on or off at any time with Ctrl-a H, or you can use the -L switch when starting screen to enable it by default. The log file is written to the current directory under the name screenlog.n, where n is incremented by one for each new log.
The logfile will contain the output of your session with corrections and cursor movements already evaluated and applied. One caveat is that programs that send control sequences to the screen will still confuse the output. One example of this is GNU ls, which by default colorizes output. You should turn this off in your session by using something like the following bash alias:

alias ls='ls --color=none'

With that, all the pieces are in place: multiple users can share a screen session for any sort of command-line-based instruction. The teacher can at any time take control of the session by switching all other users to read-only access. Finally, you can turn on the logging facilities in screen to get an accurate and usable log of the entire session (or just portions of the session if you desire).

 

I found screen to work extremely well for this purpose, and my coworker was also pleased with the results. Some of the options and controls in screen can be hard to figure out because screen is so powerful and flexible. But I plan to use this tool in the future, and I encourage anyone in a similar situation to try it.

 

 

Categories: System Administrator's Guide
Comments are closed.