Andrew, In general a "one time" emergency, and "remote help" will be two different situations. But I see no reason the split the ability into two different projects/solutions, and the end-result is the same: a remote user gains access (securely) to your system, in order to fix a problem. I also see the functions/process that we are working out in the so-called remote recovery soultion being reused for a "remote help" solution, and feel that forcing another reinvention of the wheel, or a serperate package with the same end result pointless.
I feel it would be far more simple to add a GUI control (VNC) option to the exisiting setup, allowing the helpless user or expert pick the correct course of action. I would obviosuly not waist my time using VNC to open a shell and make changes to complex system options if the user would gain no advantage by me doing so. But at the same time, it would pain me as well as the user to have two different "remote assistance" options, in which I would need to explain the diffrence. Maybe I am being a bit extreme about the extra step involved in selecting the correct soultion (if they are split), but at the same time having them combined would truly make everything easier. Package managment, bugs, etc, would all be linked anyway. I agree that the use of SSH keys in a one-time situation would be far more complex, although I think email/web would be a far better way to transfer the key then mailing them, even in a long term situation. Nonetheless the password solution should be fine, with the proper security precautions. The addition of the chroot jail will surly allow the majority of the "helpers" to feel safe. It should add that extra layer of security needed in the password situation. Altough it may be wise to disable further logins, and/or change the password after the connection has been made. I think adding a small (obvisouly simply) script for: cat ~remote-recovery/shell_out & cat > ~remote-recovery/shell_in Would be a wise option to streamline the process, but having the ability to split input and output will make this a truly robust solution. Another note on the security front, and the user learning front. I think it would be wise to echo the input and output to the "recovery" system/helpless user. This would allow them to follow along with the recovery process, and if need be interact directly. Just like VNC, they would be able to watch and possible learn, and chime in with enviroment related questions when need be. But let's for a moment assume they have no idea what the problem is, and will surly not understand the solution. The ability to watch the process does add an extra layer of security. The helpless user can monitor what the helper accesses etc. It should at the very least give them "ease of mind". It is far from fool proof, but should be an extra valuable layer, and the educational benifit is huge. And in the case of no X, this still allows the learning process to take place. And this yet again shows value in a combined solution. I think sound command-line options (like: --cli, --gui, --both [default]) would be the best approch. And with good support from the board/community, we could easily get such a solution setup with an easy to use, easy to find frontend. Shipped by default, as long as the solution is robust enough to cover a number of use cases. The one-time issue, and simple teaching/assistance are not so different in nature. Thoughts? Thanks, Justin M. Wray Sent via BlackBerry by AT&T -----Original Message----- From: Andrew Sayers <[EMAIL PROTECTED]> Date: Wed, 07 May 2008 14:06:53 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier (starting a new sub-thread for a new proposal) I'm currently swinging back towards remote recovery and remote help being distinct problems that need different solutions. There are three reasons for that: 1) As I mentioned in a previous post, remote recovery needs to be done in an extremely defencive way. Some of the things that could get users into a mess include: * Failure to mount /home * Deleting /root and/or the root account * A half-installed upgrade that leaves sshd_config messed up * /, /tmp/, /var etc. mounted read-only None of these are problems that you need to worry about in the remote help case. 2) While I definitely agree with people that say remote help should be an "over the virtual shoulder" exercise so that the user can learn some things, remote recovery is generally necessary when they've got themselves into a situation where they don't understand the problem, and wouldn't understand the solution. 3) From the point of view of remote recovery, the problem with public keys is that they're very long and difficult to type. In a remote help situation, you post someone a floppy disk with your public key on, whereas with recovery, you'd have to spell it out over the phone. My public RSA key is 200 characters, while my DSA key is 580. Speaking 1 character per second, it would take more than 3 minutes to type out an RSA key. Passwords strike me as the only practical solution for remote recovery, but I've asked the SSH team whether they would disable password authentication in the default configuration. Their opinion is the one that matters, so I'll work around them in this specific case if necessary. I'd say it's best to wait for the SSH team to reply before making decisions about remote help. The question was posted here: https://answers.launchpad.net/ubuntu/+source/openssh/+question/32326 Given all of the above, here's a rough sketch for my new remote recovery proposal: The expert tells the friend a newly-generated one-time random password that the friend can use to SSH into a chrooted jail. The jail contains two pipes: shell_in and shell_out. A superuser shell is started on the recovery machine, and all input/output to it is routed over the SSH connection and through the pipes on the expert's machine. The expert can then access a root shell on the recovery machine by doing the following on the expert's machine: cat ~remote-recovery/shell_out & cat > ~remote-recovery/shell_in This "reverse login" is definitely not great for the recovery machine's security, so it should only be used in emergencies. However, it seems to me that it should be extremely robust in the face of breakage on the recovery machine. Going back to a point I made earlier, this isn't an everything-proof solution. For example, it's no use if the expert's ISP is running a NAT that the expert can't control (as my ISP seems to be threatening to do). However, that sort of thing strikes me as a problem best left for version 2, when we start to see what the actual problems are in the real world. - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
