From the Canyon Edge -- :-Dustin

Monday, April 27, 2009

Teaching a Class with GNU Screen

I led an Ubuntu Open Week session earlier this morning on screen-profiles.

As part of the session, I setup a demo on an Amazon EC2 instance running Ubuntu 9.04. In that shared screen session, I as the "teacher" had read/write access to the instance, and 50+ "students" had read-only access. This proved incredibly handy for doing such a demonstration!

I did, however, have to configure a number of things manually to enable screen to operate safely and securely in such a shared environment.

A number of people asked me how I did this, so I thought I'd document those steps here...

  1. The screen binary must be setuid root. There are plenty of reasons why we don't do this by default in Ubuntu! However, this is absolutely required to use the multiuser feature of screen:
    $ sudo chmod 6755 /usr/bin/screen.real
  2. Once we've changed this, we must now change the permissions on the shared run space:
    $ sudo chmod 755 /var/run/screen
  3. Now, launch screen, title it "class", and select the light profile:
    $ screen -S class
  4. Next, add the following screen configuration parameters in your ~/.screenrc:
    # Ensure that permissions are propagated to all new windows
    aclumask guest+r guest-w guest-x
    # Give your guests read, but not write or execute permissions
    aclchg guest +r-w-x "#?"
    # Allow your guests to switch among windows, and detach
    aclchg guest +x "prev,next,select,detach"
    # Enable multiuser
    multiuser on
  5. And reload your profile with F5
  6. Next, edit /etc/ssh/sshd_config, and add this to the very end, to ensure that our guest user can login with a password, no forward ports, and only launch this one command:
    PasswordAuthentication yes
    AllowTcpForwarding no
    Match User guest
    ForceCommand screen -x ubuntu/class
  7. Also, if this is Amazon EC2, you'll need to enable password authentication in /etc/ssh/sshd_config with:
    PasswordAuthentication yes
  8. Now, let's add our guest user, set a password, and ensure that your guest users cannot mess with one another:
    $ sudo adduser guest
    $ sudo chown -R root:root /home/guest
    $ sudo touch /home/guest/.screenrc
  9. And restart sshd to get your configuration changes to apply:
    $ sudo service ssh restart
At this point, you should be able to direct your guests to ssh into your Ubuntu server instance. Upon login, they should immediately be connected to your shared screen session, and should only have access to:
  • F3 (previous window)
  • F4 (next window)
  • F6 (detach)
For more information, see the resources I used to compile this information:



  1. Hm... That gave me an idea. screen by default on ssh session. How many times did your network connection broke while editing some stuff on server? With ADSL this happens quite often. Now, if SSH would start screen on authentication, that could save us the trouble. If link would break again, user would reconnect, and get reattached to the screen session.

  2. Great, thanks for sharing this Dustin!

  3. Very nice indeed :)

    I use these sessions in combination with apparmor to teach on IRC.

    Here is how I do it :)

  4. Why are you using chmod? dpkg-statoverride will persist across package upgrades.

    sudo dpkg-statoverride --add root utmp 6755 --update /usr/bin/screen.real

  5. Hey Dustin, I have tried to run this on recent ubuntu 11.04, and there is no screen.real anymore. Assuming all the above steps remain the sames except for changing permissions on

    sudo chmod 6755 /usr/bin/screen

    When I want to try the session I get

    Cannot identify account 'ubuntu'.
    Connection to closed.

    Any leads to what could be wrong?


Please do not use blog comments for support requests! Blog comments do not scale well to this effect.

Instead, please use Launchpad for Bugs and StackExchange for Questions.