Fw: Suggestion to make remote recovery easier

[Justin M. Wray]

Forwarding to the list...

Thanks,
Justin M. Wray

Sent via BlackBerry by AT&T

-----Original Message-----
From: "Justin M. Wray" <wray.justin.ubuntu at gmail.com>

Date: Wed, 7 May 2008 16:55:46 
To:"Andrew Sayers" <andrew-ubuntu-devel at pileofstuff.org>
Subject: Re: Suggestion to make remote recovery easier


Yes, this seems to be the robust sort of approch that seems to cover the most use cases and works at a very low level.

Thoughts on crytpecat verses socat?  It has the benifit of being more secure.  I think the solution should work as such:

1). Try SSH, if fail then,
2). Try cryptcat, if fail then,
3). Try socat

There will be times when cryptcat will be broken (lib issues etc), so having socat as the last resort seems safe.  But for the sakof passwords and data I do not think it should be the first option.  In addition SSH is far more robost with added complexity, if it is avaliable, I think it should be used.

Thoughts?

The ability to have:
1) A VNC-based GUI
2) An X-based GUI (for e.g. broken video cards)
3) A screen-based TUI (for those of us that love screen)
4) A pty-based TUI (so that editors like vi work)
5) A pipe-based TUI (for dire emergencies)
6) A non-interactive mechanism for swapping keys

Adding only:

7) Custom command

This is the exact sort of options I think should be avaliable in such a solution.  Allowing the "helpless user" pick when running the recovery command.

The best connection solution is a reverse connection to the helpless user, this bypasses the NAT/Firewall issues.  Ssh allows tunnleing, so when possible we should use this (see above).

Else we may want to look into `rrs` (remote reverse shell).

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 17:38:05 
To:ubuntu-devel-discuss at lists.ubuntu.com
Subject: Re: Suggestion to make remote recovery easier


On the other hand, I'm wrong about that :)

I've just discovered a package called socat, which is an extremely
general command line tool for creating connections between things - more
so even than netcat.  It's in Universe, so it's presumably not that much
of an ask to have it upgraded to main.  I think we can create a general
solution using socat.  In the catastrpohic case, this would work if only
socat and a shell script were still working (instead of ssh and a shell
script).

Let's formulate the problem this way:

We need to create a bidirectional, secure method of communication
between two computers.  Some of the ways to set this up include:

1) Helpee connects to helper
2) Helper connects to helpee
3) Helpee and helper both connect to some shared proxy server

Each of these can be done over IPv4 or IPv6, over the public Internet or
a private connection (such as a modem).

Once the connection is made, we need to start up an arbitrary interface
using that channel.  Possible interfaces include:

1) A VNC-based GUI
2) An X-based GUI (for e.g. broken video cards)
3) A screen-based TUI (for those of us that love screen)
4) A pty-based TUI (so that editors like vi work)
5) A pipe-based TUI (for dire emergencies)
6) A non-interactive mechanism for swapping keys

We can implement this using a collection of interface modules that
request a particular type of connection from socat, and a collection of
socat modules that deliver that connection over whichever protocol has
been configured.

Users can then add extra socat modules to handle their own esoteric
situations.

Does this seem workable?

	- 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