Suggestion to make remote recovery easier

[Justin M. Wray]

I agree with your generalization, and ordering.  It provides fault tolerance, security, and usability.  Making the entire process esasier (the main goal of this project).

I am unsure if I feel adding a numeric value to each option is needed, when simple programming conditions can handle the tasks.  I think the numbers (bids) adds some uneeded complexity/confusion.

The robustness and power of the solution we are now talking about exceeds the power of simple shell scripts and code hacks, thus needing a higher level language.  But I personally see this as a good thing (speed, security, etc).

I think it would be best to go through each option as you have them listed, and try them, once.  If it works use it, if not move on.  Only prompt the user if we get to an insecure option.  But at the same time I think the "helpless user" should have the ability to over-ride the option, or the "helper" over-ride the option (with approval from the helpless) at start.

A GUI front-end would le such choices be easily made.  And an expert can easily tell the "helpless" to type --telnet at the end of the command.

One more note, if we do use something like 'c' we could easily add a socket into the app itself.  So we would have the following options, in said order:

1) SSH
2) bash->socat->cryptcat
3) bash->socat->netcat
4) bash->socat
5) telnet
6) bash->socket

(I've changed the order around a bit, to what I think would more secure and sound.)

And after connection, having the following recovery options:

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 
7) Custom command

(Which should have been selected when the recovery-command was first run.)

It seems like we are on track, what do you think?

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


Having looked quickly at cryptcat, it seems like some interfaces would
be best served by cryptcat+socat, so that you can get security and a
pseudo-terminal.  To generalise your idea even further, how about a
bidding system?  For example, say the expert asks for a forward remote
shell on the friend's computer:

First, the program asks for a shell connection to the specified IP address:

* SSH doesn't have that IP address in its known_hosts file, so it bids 90
* bash can create a login, but has to sub-contract creation of the PTY.
 It bids 99, on condition that someone else handle the PTY
* telnet can't do security, so bids -1 (i.e. get confirmation before
continuing)

Since a bid exists that has conditions, we do a second round of bidding.
 In the second round, the program asks for a PTY on the specified address:

* socat bids twice:
  - 99, on condition that someone else handle the connection
  - 49 if it has to handle the connection itself

Since there's still a bid with conditions, the third round asks for a
connection to the server:

* SSH still doesn't know the hostname, and isn't designed for that
particular purpose, so bids 80
* cryptcat doesn't know that host name, so bids 90
* netcat can't do security, so bids -1

SSH's bid is ignored, because there's already a higher bid with SSH in it

Since no more bids have conditions, the various options are ranked first
according to the lowest bid in the chain, then according to the number
of links in the chain:

1) SSH (90/1)
2) bash->socat->cryptcat (90/3)
3) bash->socat (49/2)
4) telnet (-1/1)
5) bash->socat->netcat (-1/3)

Each of these is then tried in order.  If the program gets all the way
down to (4) without success, it asks the expert whether he wants to try
insecure connection methods (there might be nothing wrong with telnet -
for example, if the computers are already connected over a modem).

	- Andrew

Justin M. Wray wrote:
> 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

-- 
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