Ubuntu Wiki

Summary

There should be a simple, secure, robust way for a non-technical user to allow a more technical user to SSH 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.

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

Design

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 such issues. 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

The choice of opening a terminal from the GUI is for two reasons:

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

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 an implicit assumptions made in this implementation (and preferably a way of working around it), please add it.

1. Create a remote-recovery user whose home directory is /tmp/rr, and who has no useful permissions
2. Set ~remote-recovery to be chmod 500
3. Create a ~remote-recovery/password file, chmod 400
4. Give the remote-recovery user a random password, and put the password in ~remote-recovery/password
5. 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.

Then, running remote recovery should:

1. pop up a warning about how doing this gives complete control of your system to a specified computer, and should only be done at the behest of someone you trust.
2. Add the remote-recovery user to /etc/sudoers
3. Ask for the IP address and remote-recovery password of the person you'll allow access to

4. 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 that address and print the results
   2. If it succeeds, copy ".ssh/id_dsa.pub" on the remote host to

      • ~remote-recovery/.ssh/authorized_keys

        • on the local host, then touch

        ".ssh/id_dsa.pub"

        • to confirm that the copying is complete
5. Tell the user whether SSH succeeded or failed.
6. Inform the user that they can press ctrl-c to quit remote recovery.

7. Wait until w reports a remote-recovery user logged in.

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

9. When the remote-recovery user logs out, ask whether they want to wait for the user to log in again.
   1. If no, go to 10 b. else go to 7
10. Remove the remote-recovery user, remove them from sudoers, and delete their home directory

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

1. 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 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. touch ~remote-recovery/creation-timestamp
6. Create a ~/.ssh/id_dsa with no passphrase
7. Give the following information to the user:
   • The list of public IP addresses
   • The remote-recovery user's password
   • The remote-recovery user's password again, using the NATO phonetic alphabet (so that it can be spoken over the phone)
8. Make sure the SSH server is running
9. Wait until ~remote-recovery/login exists

10. sudo -u remote-recovery ssh remote-recovery@127.0.0.1 -p 2222

11. The user now has a shell on the newbie's computer, as user "remote-recovery". They can then read the password in ~/password, and sudo whatever they need to sudo.
12. When ssh session exits, remove the remote-recovery user and delete its home directory

See also

• RecoveryMode

CategoryNetworking CategoryRecovery