Using screen for remote interaction

Recently I needed to do some distance education; one of my coworkers wanted me to show him how to do software builds on Linux. The only problem was that I’m on the East Coast and he is on the West. How could I show him the build and install process? After considering some alternatives, we found our solution in GNU Screen.

I considered using the standard Unix utility script to save a log of my typing. script has several problems, not the least of which is the horrible resulting output (script saves everything, including carriage returns and corrections). In addition, this would be completely non-interactive. If my coworker had a question or needed a clarification, we would have to correspond via email afterward. That would be a frustrating experience for both of us.

Another possible solution would be to use VNC. My coworker could connect to my display, and we could alternate control of the mouse and keyboard. That approach seemed like overkill, since what I wanted to demonstrate was purely command-line work. It would also be difficult to generate a log of a VNC session. Finally, technical limitations dictated that the only way he could connect to my machine for the demonstration was over a simple SSH connection, so this dictated a purely command-line solution.

Screen is one of those tools that is hard to explain but pure genius once you see it in operation. The description from its official Web site doesn’t help much:

Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.

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. For an introduction to screen, check out this Linux.com article.

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.