Suggestion to make remote recovery easier

[Andrew Sayers]

(starting a new sub-thread for a new proposal)

I'm currently swinging back towards remote recovery and remote help
being distinct problems that need different solutions.  There are three
reasons for that:

1) As I mentioned in a previous post, remote recovery needs to be done
   in an extremely defencive way.  Some of the things that could get
   users into a mess include:

   * Failure to mount /home
   * Deleting /root and/or the root account
   * A half-installed upgrade that leaves sshd_config messed up
   * /, /tmp/, /var etc. mounted read-only

   None of these are problems that you need to worry about in the remote
   help case.

2) While I definitely agree with people that say remote help should be
   an "over the virtual shoulder" exercise so that the user can learn
   some things, remote recovery is generally necessary when they've got
   themselves into a situation where they don't understand the problem,
   and wouldn't understand the solution.

3) From the point of view of remote recovery, the problem with public
   keys is that they're very long and difficult to type.  In a remote
   help situation, you post someone a floppy disk with your public key
   on, whereas with recovery, you'd have to spell it out over the phone.
   My public RSA key is 200 characters, while my DSA key is 580.
   Speaking 1 character per second, it would take more than 3 minutes to
   type out an RSA key.

Passwords strike me as the only practical solution for remote recovery,
but I've asked the SSH team whether they would disable password
authentication in the default configuration.  Their opinion is the one
that matters, so I'll work around them in this specific case if
necessary.  I'd say it's best to wait for the SSH team to reply before
making decisions about remote help.  The question was posted here:
https://answers.launchpad.net/ubuntu/+source/openssh/+question/32326

Given all of the above, here's a rough sketch for my new remote recovery
proposal:

The expert tells the friend a newly-generated one-time random password
that the friend can use to SSH into a chrooted jail.  The jail contains
two pipes: shell_in and shell_out.  A superuser shell is started on the
recovery machine, and all input/output to it is routed over the SSH
connection and through the pipes on the expert's machine.  The expert
can then access a root shell on the recovery machine by doing the
following on the expert's machine:

cat ~remote-recovery/shell_out & cat > ~remote-recovery/shell_in

This "reverse login" is definitely not great for the recovery machine's
security, so it should only be used in emergencies.  However, it seems
to me that it should be extremely robust in the face of breakage on the
recovery machine.

Going back to a point I made earlier, this isn't an everything-proof
solution.  For example, it's no use if the expert's ISP is running a NAT
that the expert can't control (as my ISP seems to be threatening to do).
 However, that sort of thing strikes me as a problem best left for
version 2, when we start to see what the actual problems are in the real
world.

	- Andrew