Suggestion to make remote recovery easier

[Justin M. Wray]

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 <andrew-ubuntu-devel at pileofstuff.org>

Date: Tue, 06 May 2008 02:51:25 
To:ubuntu-devel-discuss at 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 at lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss