Andrew, et all, The iptable changes would be a plus, but should be configurable, with sane defaults. I personally would be upset if my current rules were altered without my approval. And it may not be feesable to completely firewall the entire system. In general, if you setup a SSH key (or use one already created), then brute-force shouldn't be a huge issue. Its just the transmission of the password to sudo. And storage thereafter that needs to be secured.
The changes to a home directory in /tmp is a smart move, incase something goes wrong, and it is a bit cleaner as well. However on some systems this may not work nicely (noexec on /tmp, etc). Remember not all "newbies" are completely lost. Someone may want assistance with a complex system or service, and likes the ease of "remote recovery", but that doesn't mean they don't manage the system properly, thus the comments above. I find it unwise to make assumtions about the users of a service/solution. It is better to come up with clear defaults, with powerful configuration options. The clean-up scripts is also a wise addition. +1 for the general idea. Remote Help should be easy to obtain, and I too have been on the "support" call debugging ssh/firewalls before I could work on the true issue. So I welcome the addition of a sound solution. I am on the road at the moment. But in a bit (few hours), I am going to sit down, review what you have already mentioned, and attempt to help workout a clear plan of action. If you have not created a blueprint, you should do so, if you would like I can assist with the creation the blueprint, etc. Thanks, Justin M. Wray Sent via BlackBerry by AT&T -----Original Message----- From: Andrew Sayers <[EMAIL PROTECTED]> Date: Tue, 06 May 2008 02:51:25 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier Milosz Derezynski wrote: > 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. I'm not sure if I follow. If you're complaining about the password on the expert's machine, I'm suggesting that the newbie SSH in to the expert first because I'm happier to assume that an expert would know how to poke a hole through their firewall/NAT router/etc. than I am to assume the same of a newbie. Once that first connection is made, everything gets tunnelled over it. If you're complaining about the password on the newbie's machine, getting them to make decisions and speak passwords is likely to add stress and errors, because they might feel silly about being asked more questions they don't know anything about, might feel silly about spelling a password out phonetically, and might (as Justin pointed out) choose a bad password. Having said all that, how would you feel about these changes: * The connect-to-remote-recovery script on the expert's machine suggests a random password, and asks if you want to choose one manually. * While waiting for an SSH connection, the connect-to-remote-recovery script on the expert's computer keeps an eye on `w` and/or the ssh log, waits for the user to press enter, then does `passwd -d remote-recovery` as soon as they do. That would make brute-forcing an SSH connection to the expert's machine impractical * The remote recovery script on the newbie's computer does `iptables -I INPUT -i ! lo -m state --state NEW -j DROP` (and the same with iptables6) before creating the remote-recovery user, and removes those rules after deleting the user. That would make brute-forcing any connection impossible, even if (for example) the newbie had set himself up a publicly-available FTP server Also, how would people feel about the following changes based on unrelated problems: * Instead of /.remote-recovery, set the user's home directory to /tmp/rr, so it works even on some weird UMSDOS partition, and gets auto-deleted if the computer gets unexpectedly rebooted * Create an init script that deletes the remote-recovery user at boot (again, in case of unexpected reboots) - 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