Re: initial observations of sfs 0.7.2 (on NetBSD)

> Date: Tue, 25 Mar 2003 04:56:16 +1100
> From: Luke Mewburn <lukem@xxxxxxxxxx>
> 
> Here's my initial impressions:

Thanks for the feedback.  I think most of the points you make sound
like good suggestions.  I hope we can address at least some of them in
the next few months.

>     * I'm probably missing something, but it seems that when
>       I "sfs login" to setup my session, I still need to
>       type in my passphrase for the first rex connection as well.

This will be the case for "rex host" unless /sfs/host is a symlink to
the self-certifying pathname.  Basically if you have any symlinks to
the server's self-certifying pathname, you can just supply one of
those as argument to rex.

Right now, rex looks for symlinks by default in /sfs.  I've been
thinking for a while that it might make sense to look in multiple
places, or else to cache the results as symlinks in ~/.sfs/rex_keys/.
The idea would be 

>     * sfsagent is way too verbose, and has the annoying habit of
>       spamming the tty that you ran "sfskey login" on with various
>       diagnostic messages.

This is true.  Any suggestions on where to put the stuff?  The system
log doesn't seem right.  I am thinking maybe to put it in a file in
the user's home directory, though there's the slight annoyance that
your home directory might not yet be accessible at the time you run
sfsagent.

>     * To simplify the first startup of sfssd, the NetBSD rc.d script
>       for sfssd has the o ability to generate the hostkey.
>       Currently it just uses
>               sfskey gen -P /usr/pkg/etc/sfs/sfs_host_key
>       but this requires interactive interaction, which isn't
>       acceptable incase this runs at system startup.
> 
>       I have a local change to add '-K -l sfs_host_key'
>       to prevent sfskey asking questions, except that I'm not
>       sure of the implications of using '-K' like that.
>       "Help!"

Using -K means that the key has to be generated only using other
sources of randomness, like the OS's random device, the output of
commands like PS, etc.  Particularly at boot time, there might not be
enough randomness around.  Does that mean someone is going to break
your key?  Probably not your key, unless you are a really high profile
target.  However, I wouldn't be surprised if someday somebody
published a paper showing how if, for example, you generate ssh keys
automatically right after booting a pristine OS install, then someone
can invest a huge but tractable (e.g., months of CPU) amount of time
to recover the key with some probability.

Maybe.  Anyway, the point is that -K is there for the non-paranoid,
and it's probably fine for most purposes.  I have certainly used it
when I needed to setup SFS on a cluster of machines.  However, I'd
rather err on the side of better randomness for long-lived key
generation.  (Historically, weak randomness has been a real problem in
secure systems.)

>     * Other than these minor issues, so far SFS is looking pretty slick.
>       Good work!

Thanks.  As for registering port 4 (your next message), I think that
it requires submitting a standard and having two different
implementations, neither of which we have.  SSH used port 22 for a
long time before it became a standard.  Obviously we have to hope that
port 4 doesn't get standardized for something else, put people picking
a port might be aware of SFS and so steer clear of the port we are
using even though technically they could try to allocate it.

David