Remote

Differences between revisions 9 and 10
Revision 9 as of 2008-05-11 18:59:08
Size: 14166
Editor: cpc5-hitc4-0-0-cust472
Comment:
Revision 10 as of 2008-05-11 19:09:46
Size: 18512
Editor: cpc5-hitc4-0-0-cust472
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:

---- /!\ '''Edit conflict - other version:''' ----
Line 9: Line 7:
---- /!\ '''Edit conflict - your version:''' ----
Line 13: Line 10:

---- /!\ '''End of edit conflict''' ----
Line 26: Line 21:

---- /!\ '''Edit conflict - other version:''' ----
Line 51: Line 44:
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 about the system, and gain a new skill. The negative side-effect is that there's no easy way to transfer files between the computers. It's possible to paste a base64-encoded file in though, which accomplishes the same goal and leaves the friend with the ability to check the process. 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.
Line 57: Line 50:
---- /!\ '''Edit conflict - your version:''' ----
Line 87: Line 79:
---- /!\ '''End of edit conflict''' ----
Line 93: Line 83:

---- /!\ '''Edit conflict - other version:''' ----
This would work as a client/server system


---- /!\ '''Edit conflict - your version:''' ----

---- /!\ '''End of edit conflict''' ----
Line 162: Line 144:
 1. Wait until ~remote-recovery/login exists
 1. 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
    a. If either condition is not met, throw all remote-recovery users out and warn the friend that they've been subject to foul play
 1. Read lines of text and `write` them to the remote-recovery user's tty
 1. Remove the remote-recovery user, remove them from sudoers, and delete their home directory
 1. 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 step 1 on the recovery computer)
 If 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.
 1. Find the IP address(es) of the computer
   a. If any addresses are public (i.e. not one of the [wiki:WikiPedia/Private_network private addresses] 192.168.*, 10.*, 172.[16-31].*, or 169.254.*), the script stores them in memory
   a. Otherwise, tell the user to find their public address (e.g. through the settings page of their wireless router), and make sure that connections on port 22 are forwarded to <private IP address> port 22.
 1. Choose a password by showing the expert a prompt: "Remote recovery password [$PASS]: ", where $PASS is a previously-generated random password that is selected if the user presses <ENTER>
 1. 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
    * the password is as specified in step 3
    * Create a .bashrc that looks like this:
    {{{
touch ~/login
cat ~/.ssh/id_dsa.pub
pause
exit
}}}
 1. Create a ~/.ssh/id_dsa with no passphrase
 1. Give the following information to the user:
    * The list of public IP addresses, printed in the form:
    {{{
    12.34.56 (say: one two dot (pause) three four dot (pause) five six (pause) then press enter)
}}}
    * The remote-recovery user's password, printed in the form:
    {{{
    abc123 (say: alpha bravo charlie one two three (pause) then press enter)
}}}
 1. (note: the next three steps should be identical to their equivalents on the recovery computer)[[BR]]Wait until ~remote-recovery/login exists
 1. `passwd -d remote-recovery` - i.e. disable further logins from this account
 1. Check that `w -h remote-recovery` returns only one line of text, and ask the expert to confirm (over the phone) that the friend has logged in successfully
    a. If either condition is not met, throw all remote-recovery users out and warn the expert that they've been subject to foul play

---- /!\ '''This text was damaged by an HTTP error while editing. The page is currently being edited, and the original content will soon be restored if it's still valid''' ----

    {{{
touch ~/login
cat ~/.ssh/id_dsa.pub
pause
exit
}}}
 1. Create a ~/.ssh/id_dsa with no passphrase
 1. Give the following information to the user:
    * The list of public IP addresses, printed in the form:
    {{{
    12.34.56 (say: one two dot (pause) three four dot (pause) five six (pause) then press enter)
}}}
    * The remote-recovery user's password, printed in the form:
    {{{
    abc123 (say: alpha bravo charlie one two three (pause) then press enter)
}}}
 1. (note: the next three steps should be identical to their equivalents on the recovery computer)[[BR]]Wait until ~remote-recovery/login exists
 1. `passwd -d remote-recovery` - i.e. disable further logins from this account
 1. Check that `w -h remote-recovery` returns ore < /tmp/saved-iptables
iptables-restore < /tmp/saved-ip6tables
}}}

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

 1. (note: this should be identical to step 1 on the recovery computer)
 If 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.
 1. Find the IP address(es) of the computer
   a. If any addresses are public (i.e. not one of the [wiki:WikiPedia/Private_network private addresses] 192.168.*, 10.*, 172.[16-31].*, or 169.254.*), the script stores them in memory
   a. Otherwise, tell the user to find their public addr

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:

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.

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

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

This would work as a client/server system

There should be a pair of shell scripts, /bin/remote-recovery and /usr/bin/connect-to-remote-recovery. The former is run on the machine where support is needed (hereafter referred to as the "recovery machine"). The latter is run on the machine providing support (hereafter referred to as the "expert's machine").

In order to make it easier to access, the remote-recovery script should be available through GUI, command line, and GRUB.

Modern computers are often firewalled or placed behind NAT routers. Although non-technical users are at least as likely to have such things in place, they are more likely to know how to work around them. Therefore, the recovery machine first establishes an SSH connection with the expert's machine, then uses port-forwarding to make it possible to log in to the recovery machine's SSH server from the expert's machine.

Implementation

There should be three ways to run /bin/remote-recovery:

  • In the GRUB menu, there should be a "remote recovery" option
  • From the command-line
  • From the GUI, there should be System Tools->Remote Recovery option that runs the script in a terminal

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 alloContent-Type: application/x-www-form-urlencoded
      Content-Length: 23452
      
      action=savepage
       1. Wait until ~remote-recovery/login exists
       1. 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
          a. If either condition is not met, throw all remote-recovery users out and warn the friend that they've been subject to foul play
       1. Read lines of text and `write` them to the remote-recovery user's tty
       1. Remove the remote-recovery user, remove them from sudoers, and   delete their home directory
       1. 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 step 1 on the recovery computer) If 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. Find the IP address(es) of the computer
    1. If any addresses are public (i.e. not one of the [wiki:WikiPedia/Private_network private addresses] 192.168.*, 10.*, 172.[16-31].*, or 169.254.*), the script stores them in memory
    2. Otherwise, tell the user to find their public address (e.g. through the settings page of their wireless router), and make sure that connections on port 22 are forwarded to <private IP address> port 22.

  3. Choose a password by showing the expert a prompt: "Remote recovery password [$PASS]: ", where $PASS is a previously-generated random password that is selected if the user presses <ENTER>

  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
    • the password is as specified in step 3
    • Create a .bashrc that looks like this:
      touch ~/login
      cat ~/.ssh/id_dsa.pub
      pause
      exit
  5. Create a ~/.ssh/id_dsa with no passphrase
  6. Give the following information to the user:
    • The list of public IP addresses, printed in the form:
          12.34.56 (say: one two dot (pause) three four dot (pause) five six (pause) then press enter)
    • The remote-recovery user's password, printed in the form:
          abc123 (say: alpha bravo charlie one two three (pause) then press enter)
  7. (note: the next three steps should be identical to their equivalents on the recovery computer)BRWait until ~remote-recovery/login exists

  8. passwd -d remote-recovery - i.e. disable further logins from this account

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

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


Warning /!\ This text was damaged by an HTTP error while editing. The page is currently being edited, and the original content will soon be restored if it's still valid


  • touch ~/login
    cat ~/.ssh/id_dsa.pub
    pause
    exit
  1. Create a ~/.ssh/id_dsa with no passphrase
  2. Give the following information to the user:
    • The list of public IP addresses, printed in the form:
          12.34.56 (say: one two dot (pause) three four dot (pause) five six (pause) then press enter)
    • The remote-recovery user's password, printed in the form:
          abc123 (say: alpha bravo charlie one two three (pause) then press enter)
  3. (note: the next three steps should be identical to their equivalents on the recovery computer)BRWait until ~remote-recovery/login exists

  4. passwd -d remote-recovery - i.e. disable further logins from this account

  5. Check that w -h remote-recovery returns ore < /tmp/saved-iptables

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

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

  1. (note: this should be identical to step 1 on the recovery computer) If 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. Find the IP address(es) of the computer
    1. If any addresses are public (i.e. not one of the [wiki:WikiPedia/Private_network private addresses] 192.168.*, 10.*, 172.[16-31].*, or 169.254.*), the script stores them in memory
    2. Otherwise, tell the user to find their public addr

Recovery/Remote (last edited 2008-08-06 16:18:23 by localhost)