Suggestion to make remote recovery easier

[Andrew Sayers]

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