Sending to the list... Thanks, Justin M. Wray
Sent via BlackBerry by AT&T -----Original Message----- From: "Justin M. Wray" <[EMAIL PROTECTED]> Date: Tue, 6 May 2008 00:08:39 To:"Milosz Derezynski" <[EMAIL PROTECTED]> Subject: Re: Suggestion to make remote recovery easier A random password would be far more secure then the password set by the average user seeking this service. Far too often I see someone using things like "helpme" or "password" as the normal "newbie" cannot come up with a complex password on the spot. However, I do agree that I dislike the current way the password is retrevied by the "remote-helper". I think it would make more sense to print the random password to the screen and then allow the "newbie" to read it to the person they trust. Therefore if anythink goes wrong, there is one more layer of security, not that I think the security of a systenm should be left in the hands of a "newbie" user, it is there system. Thanks, Justin M. Wray Sent via BlackBerry by AT&T -----Original Message----- From: "Milosz Derezynski" <[EMAIL PROTECTED]> Date: Tue, 6 May 2008 01:56:50 To:"Andrew Sayers" <[EMAIL PROTECTED]> Cc:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier 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] <mailto:[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] <mailto:[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 Ubuntu-devel-discuss@lists.ubuntu.com <mailto:Ubuntu-devel-discuss@lists.ubuntu.com> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss <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 -- 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
