Remote

Revision 19 as of 2008-05-25 09:44:47

Clear message

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

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:

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 [http://www.gnomejournal.org/article/29/remote-desktop-administration-using-vino vino] and KDE's [http://docs.kde.org/kde3/en/kdenetwork/krfb/index.html 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.

[http://www.gnu.org/software/screen/ 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 install software not available in main (such as [https://launchpad.net/ubuntu/+source/socat/ socat] or [https://launchpad.net/ubuntu/+source/libio-pty-perl/ libio-pty-perl]), or require the Screen developers to use an architecture-neutral protocol that won't change between program versions.

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.

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). At best, we can assume that specified packages in main have been installed, perhaps with 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 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. There's no practical way of providing a PTY for a login shell without installing extra software, making the experience somewhat painful for the user.

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

On the friend's computer, a Python script will be used that depends on openssh-client and recommends vino | krfb. 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 shell or VNC session. A Python script is suggested because (unlike Perl) it has good IPv6 support out-of-the-box, because (according to [http://popcon.ubuntu.com/ the popularity contest]) it's one of the most widely installed packages in Ubuntu, and because (unlike C) the friend can download and run a Python script in an emergency 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, listening on port 2222. While doing so, it will tell the helper what the friend is seeing on their screen, and what information the helper should give to the friend.

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.

The program will run in two stages: connection and interaction. The connection stage creates secure bidirectional communication between computers; the interaction stage negotiates which type of session will be used, then uses it.

During the connection stage, the computers will try to connect in the following ways:

  1. the friend's computer will try to connect directly to the helper's computer on port 2222
  2. the helper's computer will SSH in to another computer on the Internet, and the friend's computer will try to connect to port 2222 on the other computer
  3. the friend's computer will SSH in to the other computer and try to connect to its localhost:2222
  4. the friend's computer will start an unencrypted, unauthenticated server on *:2223 that the helper's computer can connect to in order to forward the SSH server on the helper's computer

During the interaction stage, the friend's computer will (if necessary) send their public key for future use, and request either a shell or VNC session. Both computers will then start the relevant session type.

Implementation

This section will describe each stage in terms of the actions taken by the helper's and friend's computer, rather than an overview of the behaviour of each program in turn.

Communicating

Anchor(Communicate) At several points during the 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 colon, then the sum of Unicode code points, in hexadecimal. This checksum is cryptographically worthless, but strong enough to guard against simple 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 Colon 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 Colon 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 shown 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 = Alpha       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 = Juliet      W = Whiskey     9 = Nine
K = Kilo        X = X-ray       . = dot
L = Lima        Y = Yankee      : = colon
M = Mike        Z = Zulu

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

Message:

Connection stage

Before anything else, the friend is given 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.  In order to keep your computer safe, remember:

*** Never run this program because somebody online asked you to.
  + E-mails and instant messages can be faked by attackers.
  + Only run this program when asked over the telephone by
    somebody you trust not to break your computer.

*** Never tell anyone your password.
  + you can type passwords in yourself when the time comes

There's no security risk if you quit now.

At the start of the connection stage, the helper's computer will ask whether the friend has connected to the system before, and offer a selection of known users. It will then start an SSH daemon with a special sshd_config file that:

  • Listens on port 2222
  • only allows logins from the remote-help user
  • if the friend has connected before, allows access with that friend's (pre-shared) public key
  • otherwise, requires a random one-time password consisting of numbers and lower-case letters, which is [#Communicate communicated] to the friend
  • Does not permit port-, X11- or agent-forwarding
  • Forces the execution of a remote help script, rather than a login shell

The goal of the connection stage is to get the friend's computer to log in to this daemon.

The first step in the connection stage is to try to create a direct connection from the friend to the helper:

  1. The helper's computer asks for the IP address that the friend 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
  2. The helper then [#Communicate communicates] the IP address to the friend
  3. Using the IP address and password (or public key), the friend's computer will try to connect to the helper's computer. Note that the password must be downcased before it can be used
  4. Both computers will inform the users that this shouldn't take long, and that they should cancel any attempt that takes more than a few seconds
    • If the connection is cancelled, the remainder of this list is skipped - see below for more steps
  5. The helper's computer will explain that the friend might be asked to verify the fingerprint of the server. The fingerprint (which can be found by doing ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key) will be presented, so that it can be [#Communicate communicated] if necessary

  6. The helper's computer will disable the remote-help user's password
  7. If ps -u remote-help reports more processes than are needed for a single SSH login, all of the user's processes are killed and the server is stopped. Both users are advised that the connection has been terminated because of an attempt at foul play by some third party, and that the attempt was detected before either party was at any security risk

  8. The connection has now been made succesfully

If the computers are unable to connect directly, the helper is told that they can't make a direct connection, that there might be a NAT or firewall in the way, and that the helper should check the computer's firewall settings, and ensure that port 2222 on their NAT router forwards connections to the helper's computer.

After that, the helper is given the option to try the same IP address again (in case of a typo), or to try to proxy the connection through a server they have SSH access to. If the helper tries a direct connection again, the above steps are repeated. Otherwise, the helper is asked to manually SSH in to the server, passing the "-R 2222:localhost:2222" option to ssh. The above steps are then repeated, except that the helper is asked to type in the IP address (or hostname) of the SSH server acting as a proxy. Note that the IP address is communicated to the friend even when the hostname is entered, because the friend might not have a working DNS.

If connecting via a proxy server failed, the helper is asked whether the friend has an SSH account on the computer that was acting as a proxy. If so, the helper should ask the friend to SSH in to that computer, and should [#Communicate communicate] that the friend should pass "-L 2222:localhost:2222" as an option to ssh (emphasising the use of -L instead of -R). The steps above are then repeated, except that the IP address is always 127.0.0.1, so doesn't need to be communicated.

Finally, the helper's computer will explain that the only remaining option is to try and connect to the friend's computer, and that this is perfectly safe, but might require the friend to configure port forwarding on their router. The friend's computer will display the IP addresses of, and default gateway for, the computer. The IP addresses will be marked "(public)" or "(private)", depending on whether they're one of the [wiki:WikiPedia/Private_network private addresses] 192.168.*, 10.*, 172.[16-31].*, or 169.254.*. The gateway will be marked as "your nearest router". In a GUI, the gateway address will be a clickable hyperlink, in text mode, there will be an option to "go to your nearest router in a web browser". The helper will be asked to first try connecting to any addresses marked public, then to guide the friend through finding their actual public IP address (most likely by browsing to the IP address of default gateway). During this time, the friend's computer will be listening on port 2223 on all interfaces, and the helper's computer will try to connect to any IP addresses that are [#Communicate communicated]. When the helper successfully connects to the friend, the friend's computer listens on localhost port 2222 and forwards everything over the insecure connection on port 2223; meanwhile, the helper's computer sends information from the insecure connection to its own localhost port 2222. Connecting then continues as in the previous paragraph.

Interaction stage

The initial interaction is done using a line-based protocol, where each line MUST be terminated by the [http://www.faqs.org/rfcs/rfc822.html Intertenet standard] CRLF. After that, the connection is used in a protocol-specific way.

  1. If the friend logged in with a password, the friend's computer first sends a public key for future use, which the helper is asked to verify by [#Communicate communicating] it to the friend
  2. The helper's computer sends a space-separated line of session types that it supports. Currently, "vnc" and "shell" are defined, although helpers without X or without a VNC client might not send the "vnc" session type
  3. The friend is informed how to kill the session (and that they should do so as soon as they suspect foul play), the friend's computer waits for them to finish reading before continuing
  4. The friend's computer replies with a line containing one of the above choices (vnc if possible, else shell).
  5. If the friend's computer chose VNC, the friend's computer connects to localhost:5900, and sends the input and output of that connection over the SSH connection. Meanwhile, the expert's computer listens on localhost:5900, and sends the input and output of the SSH connection out over it
  6. If the friend chose a shell, the friend's computer creates a login shell, and prints output both to the screen and over the SSH connection, while accepting input both from the keyboard and from the SSH connection. Meanwhile, the helper's computer prints the output of the SSH session to the screen, and accepts input to it from the keyboard
  7. When the connection is finished, the helper is thanked for spreading the spirit of Ubuntu, and asked to report any bugs they encountered during the session (so they don't have to help someone out of the same hole next year)

See also


CategoryNetworking CategoryRecovery