(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
