Forwarding to the list... Thanks, Justin M. Wray
Sent via BlackBerry by AT&T -----Original Message----- From: "Justin M. Wray" <[EMAIL PROTECTED]> Date: Wed, 7 May 2008 16:55:46 To:"Andrew Sayers" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Date: Wed, 07 May 2008 17:38:05 To:[email protected] 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 [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
