Skip to content

Instantly share code, notes, and snippets.

@joaopizani
Created March 20, 2013 00:20
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save joaopizani/5201352 to your computer and use it in GitHub Desktop.
Save joaopizani/5201352 to your computer and use it in GitHub Desktop.
The README of my gnu-screen-shared repo, as of March 2013, for publication purposes.

gnu-screen-shared

GNU Screen has A LOT of interesting applications, and I like it a lot - so much that I have spent some time tinkering it.

One of the MOST interesting features that GNU Screen provides is screen session sharing. That means that you can start a screen session on your computer and OTHER USERS can connect to that screen session in order to just watch or also interact with the session. You can have a remote colleague log in to your machine via SSH using a "guest" account, for example, and only watch what you are doing, with complete security. Or you can also give the remote guest the right to write on your windows, but you can always kick him or return him to the watch-only group...

However, setting up this "environment" in a productive and secure way is hard, and you have to know about SSH keys, remote command execution restriction, etc. So I created this repository that consists of a handy script to help you setup a SSH key which sole purpose is letting someone work together with you in a shared Screen session.

You should run the script newkey.sh as the user who will create the shared Screen session. That is, if you usually use you computer (and run Screen) as the user "batman", then "batman" is the user which must run the newkey.sh

You should run the script like this:

./newkey.sh <optional_guest_username>

The parameter is optional, and indicate which account you use in your computer as a "guest" account. It's best to have a separate "guest" account only for these kinds of restricted remote accesses. But if you don't pass a parameter, the guest account is assumed to be the same as the one of the user running the script.

The keys are intended to be "temporary", meaning that you should very often generate a new pair using the script and give the private key it to whoever you want to be able to access your shared sessions. Some comments about security:

  1. You can use a passphrase or not to encrypt the private key. It does not matter that much, because at the end of the day you are supposed to generate new keys very often, making the system behave as a "one-time-key-like" system. If you decide to use a passphrase, choose, for example, something that you and your remote guest both ALREADY know, but is hard to guess.
  2. To "revoke access" of old keys, you just go to your authorized_keys file and delete the lines refering to the keys you think are too old (Each key is identified by the date in which it was created).
  3. The access line that's added to the guest user's authorized_keys file allows ONLY to join a currently-running Screen multiuser session. It allows no shell access, no port forwarding, no X11 forwarding, no other commands, basically NOTHING ELSE.

Quick tutorial on practical usage

Enough for theory, let's put the script to work. Suppose you want to share a Screen session running on your computer with a friend. You want to have a separate user account called "guestcoder" for the specific purpose of entering these shared sessions.

First you need to create the "guestcoder" user, which can be done like this:

batman@batcave:~$ sudo useradd -m guestcoder -s /bin/false

Notice how the shell is set to /bin/false so that the ONLY way for the user to get access is by using the provided restricted SSH key. The next step is to run the script to allow guestcoder to access batman's shared Screen sessions:

batman@batcave:~$ ./newkey.sh guestcoder

If everything goes well you can just send the private key to your friend (the most recently created private key lies in this repo root with the name sshare-current-key), and then you start your local Screen session, with the name "shared"

screen -S shared

Also, make sure that the multiuser mode in Screen is activated and that the guestcoder has access to it:

<Ctrl-a>:multiuser on
<Ctrl-a>:acladd guestcoder

If you happen to be using my awesome screenrc config, then the first step above is not necessary, and the second step is transformed into one of the two alternatives below, according to your taste :)

<Ctrl-a>:aclgrp guestcoder READERS  # OR
<Ctrl-a>:aclgrp guestcoder WRITERS

That's about it! Enjoy the fun of working with multiuser GNU Screen sessions, and enjoy it securely. Send me ideas or patches, I would be happy to implement any improvements to make this whole thing even easier and nicer...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment