Suggestion to make remote recovery easier

[Andrew Sayers]

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