Suggestion to make remote recovery easier

[Christopher Halse Rogers]

On 5/7/08, Andrew Sayers <andrew-ubuntu-devel at pileofstuff.org> wrote:
> At this point, I'm trying to walk the line between unrealistic "wouldn't
>  it be great if..." type ideas and overly-strict reliance on solving the
>  specific problem I have in my head, so I'd like to go back to first
>  principles for a moment.  Please tell me if any of these are false:
>
>  1) It's common for new Linux users to have a technical friend that deals
>  with their problems.  This is a healthy relationship that we should look
>  for ways to support
>  2) People generally don't formalise that sort of thing until it's too late
>  3) All Linux users can be behind arbitrarily complex sets of
>  firewalls/NAT, including multiple layers of NAT or firewalls, not all of
>  which are under either user's control
>  4) We can expect experts to do some considerable work (e.g. installing
>  packages and configuring routers), but non-technical users need simple
>  instructions from the default installation
>  5) There's some interest in making small changes to the default install
>  to cater to the above issues
>  6) Since the people in most need of help are more likely to stick to LTS
>  releases, we can afford to add this sort of feature gradually, and see
>  what public reaction is like
>
>  The basic solution we're looking at here is to make it possible for the
>  technical friend to set up an SSH connection to the non-technical
>  friend's computer, using an account that has some way to execute
>  superuser commands (with sudo or by actually being the root user).  This
>  breaks down into three sub-problems:
>
>  1) Creating or modifying an account that has the necessary permissions
>  2) Creating an SSH connection
>  3) Destroying or reverting an account to its original state
>
>  In (1) and (3), I had been concentrating on setting up a mechanism to
>  trust someone temporarily, but I now realise that's not a particularly
>  common use case, because if I trust you today, I will probably trust you
>  tomorrow too.  Getting people to jump through the same set of hoops
>  every time there's a problem makes life harder than necessary for
>  non-expert users, which I've been complaining about all thread.
>
>  Reliably doing (2) is a hard problem.  The solution I had come up with
>  strikes me as a good solution for a common use case, but there's no way
>  to deal with the general case without introducing more complexity.
>
The other option here might be to flip the problem around: the
technical user almost certainly _is_ in control of the NAT they're
behind, so you could try writing up a server on the techy-friend side
that a client connects to in order to get help.  This would have the
advantage that you probably don't need to care about what NAT/firewall
the helpee is behind, and might also ease some security concerns - the
helpee must explicitly start the connection, the helper can start the
server only when required, and it doesn't give shell access to anyone
who connects.  And the obvious disadvantage that this client/server
needs to be written.