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. Current solutions are secure, robust or simple, but never more than two out of three.

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

Remote help assistant is a program being developed based on this specification.

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 that sub-areas within a window are referred to as tabs.

Other Projects

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

• LoCo Remote

• 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.

GNOME's vino and KDE's krfb provide VNC access to a computer. These provide an excellent basis for allowing the helper to connect to a computer with a functioning X server, although this tool needs to add a command-line mode, the ability to route around NAT and firewalls, and an effective mechanism for communicating security information over the telephone. To reinforce the last point, both vino and krfb expect users to send invitations by e-mail, but non-technical users can't be expected to have PGP-encrypted e-mail already set up, and it would be impractical to set it up for them over the phone.

GNU Screen provides shell access to multiple users, but isn't designed for use across multiple computers. To adapt it for this purpose, we would have to find some way of exporting a pseudo-terminal over a network.

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 to allow incoming connections on specified ports, but this can't be assumed in the general case.

The friend's computer can't be assumed to have a particularly large set of packages installed and functioning, as they might have removed important packages (or broken them in a more imaginative way). In this blueprint, it will be assumed that the friend has installed packages that are installed in at least 99% of cases reported to the Ubuntu popularity contest, not necessarily with functioning configuration files. Systems more broken than this would be better served by (semi-)automated recovery scripts that can solve specific problems, or by booting to a live CD with a remote recovery script on it.

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 can be assumed to maintain those packages properly.

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.

Man-in-the-middle attacks are a serious security issue here. If helper and friend haven't already exchanged security information (such as SSH keys), a tamper-proof connection is needed in order to confirm the connection they're using. A telephone conversation is sufficiently tamper-proof for purposes of this project - albeit a channel with severely limited bandwidth. Other systems (such as instant messaging or e-mail) are not sufficiently tamper-proof, and should not be recommended. Since users will use insecure channels no matter what recommendations we make, the following rules should apply, as a second line of defence:

• 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 transfer files by pasting base64-encoded text, 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 can read, 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 login shell, these conditions can be met by ensuring that both users have read and write access to the shell, and that the session is terminated when the friend types ctrl-alt-c, or some other special sequence.

Design

This program will be written as a single file in a scripting language, so that it can simply be downloaded and run in an emergency, no matter the architecture the user uses. Python is a good choice for the scripting language because in a default Ubuntu installation, Python supports creating pseudo-ttys (necessary for creating a fully functional shell session) and IPv6 (necessary to talk to Vino), which are only available in Perl if you install extra packages. Although the Ubuntu popularity contest ranks Python lower than Perl, both packages are installed and regularly used in well over 99% of popcon results.

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

Connecting the helper and friend will be a seven step process:

1. Information: Welcome, explanation of what the program does, warnings about security

2. Question: Run in helper of friend mode?

3. Question:

   1. If in helper mode, information about what the friend needs to know in order to contact the helper
   2. If in friend mode, IP address of the helper, and an option to automatically run a VNC server (if one isn't running already)
   Both users also get the option to automatically manage their firewall, and to use a reverse connection (explained below)

4. Wait: both users are asked to wait while the computers connect to one another and exchange information

5. Question: both users are asked to verify the SSH keys that will be used to secure the connection

6. Wait: the friend's computer tries to start a VNC server, the helper's computer waits to hear what type of session to run

7. Information: Your connection has been set up, how to close the connection, etc.

In friend mode, the answers to questions should default to the values used by the last successful connection. This is because friends normally only have one helper, but helpers normally have several friends.

To work properly, the program needs connections made over the local loopback interface never to be firewalled in IPv4 or IPv6, and to be able to communicate freely to and from IPv4 TCP port 2222. Inexperienced users might have put firewall rules in place that break this program, while experienced users would be upset if the program modified their firewall behind their backs. Therefore the user is offered the option to have the program poke the relevant holes in the firewall, but the option is disabled by default.

Because helpers are more likely to be able to work around NAT, the program connects from friend to helper by default. Using a reverse connection forces the helper's computer to connect to the friend's instead.

Once an (insecure) connection has been established, the computers swap SSH keys, usernames, and whether they have an SSH server installed. One user will need to have an SSH server installed (but not necessarily running) in later stages, although it doesn't matter who.

When verifying one another's SSH keys, users will be shown the key both as plain text and in the NATO phonetic alphabet, so that they can unambiguously speak it over a phone line. The computers have already exchanged keys over an insecure connection, so the purpose of this stage is just to verify the keys (in case of a man-in-the-middle attack).

Ideally, Python's SSL sockets would be used to secure the connection, but their poor documentation and lack of obvious way to extract SSH key information from a session make them an unwise choice. Beyond the programming obstacles, these issues suggest that Python's SSL implementation has too few eyeballs on it to be trustworthy in a security context. Instead, an SSH client and server will be used as a poor man's cryptography library. Because a connection has already been established, communication with the SSH client and server will be done over the local loopback interface, and the encrypted data transferred over the already-established connection. This saves users the need to open up a second public port for the SSH server to listen on, or to wait while the connection on port 2222 is torn down.

Once the SSH connection has been established, the friend's computer will try to connect to a local VNC server, and will advertise a VNC session if it finds one. Otherwise, it will advertise a shell session.

See also

• RecoveryMode

• Discussion on the ubuntu-devel-discuss mailing list

• Remote help assistant

CategoryNetworking CategoryRecovery