Ubuntu Wiki

Summary

There should be a simple, secure, robust way for a non-technical user to allow a more technical user to connect to their computer and get root access, using only instructions that can be described simply, in layman's terms, over a poor quality phone line. The facility to allow the technical user access should be available, and easily visible, in the default install.

In this document, the technical user is referred to as the "helper", and the non-technical user as the "friend".

There should be a simple, secure, robust way for a non-technical user to allow a more technical user to connect to their computer and get root access, using only instructions that can be described simply, in layman's terms, over a poor quality phone line. The facility to allow the technical user access should be available, and easily visible, in the default install.

In this document, the technical user is referred to as the "helper", and the non-technical user as the "friend".

Rationale

For experienced Linux users, over-the-phone tech support for a non-technical friend is a common use case. It's normally an unpleasant experience, for the following reasons:

• Telephones often have poor audio quality. For example, it's hard for the friend to tell whether you're saying "less" or "ls"
• Describing what command lines to type can be socially awkward. For example, do you tell them where to put spaces and when to press enter? Making the wrong decisions will either insult your friend or make them feel even more helpless than they feel already
• It's very difficult for a friend to accurately describe what they're seeing on their screen. For example, most people don't know how to pronounce "~" or what a backtick is

Other Projects

Several projects aim to provide complete application suites that handle tasks such as remote support. Included among them is:

• [https://launchpad.net/locoremotesupport/ LoCo Remote]

• [https://launchpad.net/telepathy Telepathy]

This project would not provide a complete suite, just a tool to enable remote connections to be made. Complete solutions aren't appropriate to a support request made over the phone.

Overview of the problem

Both helper and friend might be behind a NAT router or a firewall beyond their control. It's more likely that the helper would be able to configure their network so as to allow incoming connections on specified ports, but this can't be assumed in the general case.

If the friend has an X session running, the helper should be given access to it over a VNC connection. Otherwise, the friend should be given a login shell on the user's machine. For reasons discussed below, [https://launchpad.net/screen screen] is the preferred tool for this, although it may be necessary to reinvent that particular wheel.

The friend's computer can't be assumed to have a particularly large set of packages installed and functioning, as they might need help because they've broken important packages, or might have decided that they didn't like the look of some packages and decided to uninstall them. At best, we can assume that specified packages in main have been installed, and may or may not have functioning configuration files. Any system more broken than this would be better served by (semi-)automated recovery scripts that can solve specific problems.

The helper's computer can be assumed to have a much more complete system, because people with sufficient expertise and patience to help out can reasonably be asked to install packages outside of main, and not to find imaginative ways of breaking them.

Man-in-the-middle attacks are a serious security issue here. If the helper and friend are talking to one another on the phone, they have a largely tamper-proof connection to one another, albeit one where bandwidth is severely limited. If they're communicating over some other system (such as instant messaging), there's no tamper-proof connection between them. If helper and friend haven't already exchanged security information (such as SSH keys), there is no full-proof defence against MITM attacks without a tamper-proof connection available. Therefore, the following security precautions should be taken:

• The helper should never be able to do anything behind the friend's back. Anything the helper does should be visible to the friend
• passwords and other important security information should never be transferred over the connection
• The friend should have an easy way of terminating the session, and should be aware of that method

The first of these conditions have two important side-effects, one positive, one negative. The positive side-effect is that the friend has the opportunity to learn a little by watching the helper. The negative side-effect is that there's no easy way to transfer files between the computers. It's possible to transer files by pasting base64-encoded files, which accomplishes the same goal and leaves the friend with the ability to check the process.

The second condition can be met by ensuring that, as well as reading anything the helper does, the friend can write anywhere that the helper can write. Therefore, if the helper needs a password, the friend can type it in without telling the helper.

Over a VNC connection, these conditions are trivially met - both users share a session, and the friend can terminate the session by pressing ctrl-alt-backspace. Over a [https://launchpad.net/screen screen], these conditions can be met using a multi-user screen, and by ensuring that the screen session is terminated when the friend disconnects from it. If it's necessary to reinvent screen, a way to meet these criteria will have to be found.

Design

On the friend's computer, a Perl script will be used that depends on openssh-client, x11vnc, and screen. The x11vnc package is currently in universe, the others are in main. The script will ask the friend for certain details (such as the helper's IP address), and will describe what will happen as it tries to set up a screen or VNC session. A Perl script is suggested because (according to [http://popcon.ubuntu.com/ the popularity contest]) it's one of the most widely installed packages in Ubuntu, and in an emergency, the friend can download and run it without needing to compile it for their particular architecture.

On the helper's computer, a program will attempt to let the friend connect to a special purpose SSH daemon. While doing so, it will tell the expert what the friend is seeing on their screen, and what information the expert should give to the friend.

In order to make it easier to access, the Perl script on the helper's computer should be available through the recovery menu in single user mode, and through System Tools->Share my Desktop from the GUI.

The computers will attempt to connect three ways:

1. the friend's computer will try to connect directly to the helper's computer
2. both computers will ask if there is a shared server they can exchange messages through
3. the friend's computer will ask permission to install an SSH daemon that the helper can connect to

Note that in the final case, the connection from the helper to the friend's computer would only be used to forward a port that lets the friend SSH in to the helper's computer. Although a secure way could be found to only use a single connection, the extra complexity isn't worth the minor speed advantage it would gain.

Once the connection is made, the friend's computer will (optionally) send their public key for future use, will request either an screen or VNC session, and will then be connected to such a session.

Implementation

This system will take the form of two interacting programs on two computers.

Helper's computer

1. When the program on the helper's computer is run, it will then ask whether the friend has connected to the system before, and offer a selection of known users.
2. It will then start a special-purpose SSH daemon that allows a heavily locked-down user to connect
   1. if the friend has connected before, it will allow access with the friend's (pre-shared) public key b. otherwise, it will require a random one-time password consisting of numbers and lower-case letters, that will be communicated to the user as described in the "communicating technical data" section, below
3. It will ask what IP address the client should connect to. This is normally one of the computer's IP addresses, but might be the IP address of a router if the computer is behind a NAT
4. Then it will tell the helper to communicate that IP address to the friend
5. The user will have very few permissions. Depending on the type of session, they will be allowed to read and write to sockets in a single directory (in the case of a screen session), or to listen on localhost port 5901 for VNC connections. Some of the ways these users will be locked down include:
   • They will not be given a login shell
   • They will not be allowed to forward local or remote ports, or X connections (except for port 5901, which will piped through standard input/output)

   • The program used instead of a shell will be protected with AppArmor

   Although putting these users in a chroot jail was considered, it was felt not to provide sufficient extra protection, given the above measures.
6. When a connection is made, the program immediately stops the server, so as to reject any further connections.
7. If the friend logged in with a password, the friend's computer must immediately send a public key for future use.
8. The helper's computer then sends a space-separated line of text listing the types of sessions it supports. Currently, "vnc" and "screen" are defined.
9. The friend's computer replies with a line containing one of those choices.

10. The input from, and output to, the SSH connection are piped through to either a server listening on port 5901, or a Unix socket at /var/run/screen/S-$helpers_username/$PID.remote-help.$helpers_computer_name

11. The helper will be asked either to point their favourite VNC client at localhost:5901, or to attach to the specified screen

Communicating technical data

At several points during the connection process, users will be asked to send out-of-band information to one another - for example, the friend will need to be told the IP address of the helper. Because this might involve correct spelling over a phone line, users will need to be given the text normally and in the [wiki:WikiPedia/NATO_phonetic_alphabet NATO phonetic alphabet]. As an additional safety measure, messages are also given a checksum, consisting of the number of characters sent, a dash, then the sum of Unicode code points, in hexadecimal. This checksum is cryptographically worthless, but strong enough to guard against typos.

When a message is sent, the sending user should be shown a message like the following:

Please pass the following message to your friend.

If speaking to them, tell them to type:
        Alpha Bravo Charlie One Two Three ENTER
        Six Dash One Bravo Charlie ENTER
Otherwise, tell them to type:
        abc123 <enter>
        6-1bc <enter>

It doesn't matter whether you type this in upper or lower case.

When a message is received to be verified, the receiving user should be shown a message like the following:

Please verify the message your friend reads out to you.

If they're speaking to you, they should say:
        Alpha Bravo Charlie One Two Three ENTER
        Six Dash One Bravo Charlie ENTER
Otherwise, they should type:
        abc123 <enter>
        6-1bc <enter>

When a message is received to be typed, the receiving user should be show a message like the following:

Your friend will now tell you to type two lines of text.  If speaking
to you, your friend will spell the message out phonetically.  Here's
the alphabet that will be used:

A = Alfa        N = November    0 = Zero
B = Bravo       O = Oscar       1 = One
C = Charlie     P = Papa        2 = Two
D = Delta       Q = Quebec      3 = Three
E = Echo        R = Romeo       4 = Four
F = Foxtrot     S = Sierra      5 = Five
G = Golf        T = Tango       6 = Six
H = Hotel       U = Uniform     7 = Seven
I = India       V = Victor      8 = Eight
J = Juliett     W = Whiskey     9 = Nine
K = Kilo        X = Xray
L = Lima        Y = Yankee
M = Mike        Z = Zulu

It doesn't matter whether you type this in upper or lower case.

Message:

Opening a terminal from the GUI is a better decision than creating a second (graphical) interface because:

• It's more important that this system be bug-free than pretty. The extra complexity of a second interface introduces the chance to create more bugs
• A second interface adds more opportunity for confusion between expert and friend: "okay, now press ente... er no, click on OK... or Continue, or Save, or whatever it is..."

There should be an init script that:

• deletes the remote-recovery user if it exists
• deletes /tmp/rr if it exists
• runs /bin/remote-recovery if the remote recovery option is specified in GRUB

/bin/remote-recovery

Ideally, this script should work from first principles, assuming nothing about the system (e.g. that /usr is mounted, that ssh is installed). If you can think of implicit assumptions made in this implementation (and preferably workarounds for them), please add them.

1. (note: this should be identical to step 1 on the expert's computer)BRIf the SSH server isn't running, enable it. If it won't enable, try various things:

   • If the package doesn't exist, ask if you can install it

   • If /usr or /usr/bin doesn't exist, check whether they're mentioned in /etc/fstab, and if so, whether they're mentioned in mount, then tell the user what's going on, and offer to print the contents of both.

2. Remember the current iptables settings by doing:

   • iptables-save > /tmp/saved-iptables
     ip6tables-save > /tmp/saved-ip6tables

3. To work around any firewalls the user has set up, and to avoid security issues if (for example) the user has set up an FTP server that an attacker could brute-force the remote-recovery password through, do:

   • iptables -I INPUT 1 -m state --state NEW -j DROP
     iptables -I INPUT 1 -i lo -m state --state NEW -j DROP
     iptables6 -I INPUT 1 -m state --state NEW -j DROP
     iptables6 -I INPUT 1 -i lo -m state --state NEW -j DROP

4. Create a remote-recovery user
   • the home directory is /tmp/rr
   • they are in their own group, and have no useful permissions
   • their home directory is chmod 500
   • they have a randomly chosen password (the user is not asked about this)
   • Create a .bashrc that looks like this:

     touch ~/login
     cat <<EOF
     Welcome to the recovery mode
     
     This file should be populated with various information and warnings, including:
     
     * changes to iptables rules will be destroyed unless they're saved to /tmp/saved-ip*tables
     * You can sudo things using the password in ~/password
     * The recovery-mode script allows messages to be sent to you using the `write` command.  You can use `write` to send messages back
     EOF

5. Print the following warning:

   • This program gives complete control of your computer to someone else on the Internet, so that they can help solve any problems you are having.
     
     While running this program, you will be asked for a passwords, and asked to confirm when the person fixing your computer has logged in.  You should get confirmation of these details over a phone line, so that you can be sure that you're talking to the person you think you're talking to.  In particular, you shouldn't send passwords over e-mail or instant messaging.
     
     *** Only run this program at the request of somebody you trust, when talking to them on the telephone ***
     
     There's no security risk if you quit the program now.  Type "continue" then press enter to continue, or anything else to quit

   • if they type "continue" (lower-case only), continue. b. otherwise, stop
6. Prompt the user to enter the IP address of the computer you'll allow access to
7. Prompt the user to enter the remote-recovery password of the person you'll allow access to

8. ssh remote-recovery@$ip_address -L22:localhost:2222

   1. if that fails, do various diagnostics:
      • Does the computer have an IP address? Does it have a gateway?
      • Do a tracepath to $ip_address and print the results

   2. If it succeeds, read the line beginning "ssh-dsa " and append it to ~remote-recovery/.ssh/authorized_keys

9. Tell the user whether SSH succeeded or failed.
   1. If it failed, explain why then stop.
10. Inform the user that they can press ctrl-c to quit remote recovery.
11. Wait until ~remote-recovery/login exists

12. Check that w -h remote-recovery returns only one line of text, and ask the friend to confirm (over the phone) that the expert has logged in successfully

    1. If either condition is not met, throw all remote-recovery users out and warn the friend that they've been subject to foul play

13. Read lines of text and write them to the remote-recovery user's tty

14. Remove the remote-recovery user, remove them from sudoers, and delete their home directory
15. Restore old iptables by doing:

    • iptables-restore < /tmp/saved-iptables
      iptables-restore < /tmp/saved-ip6tables

/usr/bin/connect-to-remote-recovery

1. (note: this should be identical to stepve > /tmp/saved-iptables

ip6tables-save > /tmp/saved-ip6tables }}}

1. To work around any firewalls the user has set up, and to avoid security issues if (for example) the user has set up an FTP server that an attacker could brute-force the remote-recovery password through, do:

   • iptables -I INPUT 1 -m state --state NEW -j DROP
     iptables -I INPUT 1 -i lo -m state --state NEW -j DROP
     iptables6 -I INPUT 1 -m state --state NEW -j DROP
     iptables6 -I INPUT 1 -i lo -m state --state NEW -j DROP

2. Create a remote-recovery user
   • the home directory is /tmp/rr
   • they are in their own group, and have no useful permissions
   • their home directory is chmod 500
   • they have a randomly chosen password (the user is not asked about this)
   • Create a .bashrc that looks like this:

     touch ~/login
     cat <<EOF
     Welcome to the recovery mode
     
     This file should be populated with various information and warnings, including:
     
     * changes to iptables rules will be destroyed unless they're saved to /tmp/saved-ip*tables
     * You can sudo things using the password in ~/password
     * The recovery-mode script allows messages to be sent to you using the `write` command.  You can use `write` to send messages back
     EOF

3. Print the following warning:

   • This program gives complete control of your computer to someone else on the Internet, so that they can help solve any problems you are having.
     
     While running this program, you will be asked for a passwords, and asked to confirm when the person fixing your computer has logged in.  You should get confirmation of these details over a phone line, so that you can be sure that you're talking to the person you think you're talking to.  In particular, you shouldn't send passwords over e-mail or instant messaging.
     
     *** Only run this program at the request of somebody you trust, when talking to them on the telephone ***
     
     There's no security risk if you quit the program now.  Type "continue" then press enter to continue, or anything else to quit

   • if they type "continue" (lower-case only), continue. b. otherwise, stop
4. Prompt the user to enter the IP address of the computer you'll allow access to
5. Prompt the user to enter the remote-recovery password of the person you'll allow access to

6. ssh remote-recovery@$ip_address -L22:localhost:2222

   1. if that fails, do various diagnostics:
      • Does the computer have an IP address? Does it have a gateway?
      • Do a tracepath to $ip_address and print the results

   2. If it succeeds, read the line beginning "ssh-dsa " and append it to ~remote-recovery/.ssh/authorized_keys

7. Tell the user whether SSH succeeded or failed.
   1. If it failed, explain why then stop.
8. Inform the user that they can press ctrl-c to quit remote recovery.
9. Wait until ~remote-recovery/login exists

10. Check that w -h remote-recovery returns only one line of text, and ask the fr