Suggestion to make remote recovery easier

Wed May 7 13:53:12 UTC 2008

Andrew,

In general a "one time" emergency, and "remote help" will be two different situations.  But I see no reason the split the ability into two different projects/solutions, and the end-result is the same: a remote user gains access (securely) to your system, in order to fix a problem.  I also see the functions/process that we are working out in the so-called remote recovery soultion being reused for a "remote help" solution, and feel that forcing another reinvention of the wheel, or a serperate package with the same end result pointless.

I feel it would be far more simple to add a GUI control (VNC) option to the exisiting setup, allowing the helpless user or expert pick the correct course of action.  I would obviosuly not waist my time using VNC to open a shell and make changes to complex system options if the user would gain no advantage by me doing so.  But at the same time, it would pain me as well as the user to have two different "remote assistance" options, in which I would need to explain the diffrence.  Maybe I am being a bit extreme about the extra step involved in selecting the correct soultion (if they are split), but at the same time having them combined would truly make everything easier.  Package managment, bugs, etc, would all be linked anyway.

I agree that the use of SSH keys in a one-time situation would be far more complex, although I think email/web would be a far better way to transfer the key then mailing them, even in a long term situation.  Nonetheless the password solution should be fine, with the proper security precautions.

The addition of the chroot jail will surly allow the majority of the "helpers" to feel safe.  It should add that extra layer of security needed in the password situation.  Altough it may be wise to disable further logins, and/or change the password after the connection has been made.

I think adding a small (obvisouly simply) script for:

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

Would be a wise option to streamline the process, but having the ability to split input and output will make this a truly robust solution.

Another note on the security front, and the user learning front.  I think it would be wise to echo the input and output to the "recovery" system/helpless user.  This would allow them to follow along with the recovery process, and if need be interact directly.  Just like VNC, they would be able to watch and possible learn, and chime in with enviroment related questions when need be.

But let's for a moment assume they have no idea what the problem is, and will surly not understand the solution.  The ability to watch the process does add an extra layer of security.  The helpless user can monitor what the helper accesses etc.  It should at the very least give them "ease of mind".  It is far from fool proof, but should be an extra valuable layer, and the educational benifit is huge.

And in the case of no X, this still allows the learning process to take place.  And this yet again shows value in a combined solution.  I think sound command-line options (like: --cli, --gui, --both [default]) would be the best approch.

And with good support from the board/community, we could easily get such a solution setup with an easy to use, easy to find frontend.  Shipped by default, as long as the solution is robust enough to cover a number of use cases.

The one-time issue, and simple teaching/assistance are not so different in nature.

Thoughts?

Thanks,
Justin M. Wray

Sent via BlackBerry by AT&T

-----Original Message-----
From: Andrew Sayers <andrew-ubuntu-devel at pileofstuff.org>

Date: Wed, 07 May 2008 14:06:53 
To:ubuntu-devel-discuss at lists.ubuntu.com
Subject: Re: Suggestion to make remote recovery easier

(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

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss at lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss