There is IMO no real need for a random password; instead, the user of the machine to be recovered should be allowed to enter a password which he then can tell to the user recovering the machine remotely. This doesn't neccessarily have to be more insecure; a random alphanum password is probably better secured against brute force cracking but i don't like the fact that the computer hands out a password for the user automatically, even if he gets to see it.
2008/5/5 Andrew Sayers <[EMAIL PROTECTED]>: > I'm a Linux user of sufficient experience that friends are starting to > phone me up when there's a problem with their computer. I guess most > people here know how long and painful those conversations can be, so I > think it would be better if Ubuntu had a mechanism to let me SSH into > people's computers using only instructions that I can describe to > newbies over the phone without confusing them. Of course, the problem > is doing this in a way that's both secure and robust. I've got an > approximate outline of how it would work, so could people tell me how > practical this idea is: > > * There should be three ways to enable remote recovery: > - In the GRUB menu, there should be a "remote recovery" option > - From the command-line, there should be a "remote-recovery" command > - From the GUI, there should be System Tools->Remote Recovery > * Experts should be able to run /usr/sbin/connect-to-remote-recovery to > prepare their system for a remote recovery. > > Running or connecting to a remote recovery should start by doing the > following: > > 1) Create a remote-recovery user whose home directory is > /.remote-recovery, and who has no useful permissions > 2) Set their home directory to be chmod 500 > 3) Create a ~remote-recovery/password file, chmod 400 > 4) Give the remote-recovery user a random password, and put the password > in ~remote-recovery/password > 5) If the SSH server isn't running, enable it. If it won't enable, try > various things: > * If the package doesn't exist, ask if you can install it > * If /usr or /usr/bin doesn't exist, check whether they're mentioned > in /etc/fstab, and if so, whether they're mentioned in `mount`, > then tell the user what's going on, and offer to print the contents > of both. > > Then, running remote recovery should: > > 1) pop up a warning about how doing this gives complete control of your > system to a specified computer, and should only be done at the behest > of someone you trust. > 2) Add the remote-recovery user to /etc/sudoers > 3) Ask for the IP address and remote-recovery password of the person > you'll allow access to > 4) `ssh [EMAIL PROTECTED] -L22:localhost:2222` > 4a) if that fails, do various diagnostics: > * Does the computer have an IP address? Does it have a gateway? > * Do a tracepath to that address and print the results > 4b) If it succeeds, copy ".ssh/id_dsa.pub" on the remote host to > "~remote-recovery/.ssh/authorized_keys" on the local host, then > touch ".ssh/id_dsa.pub" to confirm that the copying is complete > 5) Tell the user whether SSH succeeded or failed > 6) Inform the user that they can press ctrl-c to quit remote recovery > 7) Wait until `w` reports a remote-recovery user logged in > 8) Read lines of text and `write` them to the remote-recovery user's tty > 9) When the remote-recovery user logs out, ask whether they want to wait > for the user to log in again. > 9a) If no, go to 10 > 9b) else go to 7 > 10) Remove the remote-recovery user, remove them from sudoers, and > delete their home directory > > Alternatively, connecting to a remote recovery should do: > > 1) Find the IP address(es) of the computer > 1a) If any addresses are public (not e.g. 192.168.*.*), print them > 1b) Otherwise, tell the user to find their public address (e.g. through > the settings page of their wireless router), and make sure that > connections on port 22 are forwarded to <private IP address> port > 22. > 2) touch ~remote-recovery/password > 3) Create a ~/.ssh/id_dsa with no passphrase > 4) Print the contents of ~remote-recovery/password, then print it again, > using the NATO phonetic alphabet (so that it can be spoken over the > phone) > 5) Make sure the SSH server is running > 6) Wait until the ctime of ~remote-recovery/password is less than the > ctime of ~remote-recovery/.ssh/id_dsa > 7) `sudo -u remote-recovery ssh [EMAIL PROTECTED] -p 2222` > 8) The user now has a shell on the newbie's computer, as user > remote-recovery. They can then read the password in ~/password, and > sudo whatever they need to sudo. > 9) Remove the remote-recovery user and delete their home directory > > - Andrew Sayers > > -- > 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
