Incremental file updates over a network, NFS?

[Matt McCutchen]

On Fri, 2008-03-14 at 15:00 +0100, Andy Smith wrote:
> Ok, thanks for the info. That seems to open up the issue of network
> security (yes NFS security normally isnt great, but...)
>  
> rsyncd native: is this bug free and secure (based on
> hosts_allow/hosts_deny?), perhaps a good solution with tcpwrappers?

To elaborate on Vitorio's answer, the rsync daemon protocol begins with
an challenge-and-response authentication but neither encrypts nor
integrity-checks the actual data.  Thus, it's not a good idea to connect
directly to a daemon except on a trusted local network (or on the same
machine after the connection comes out of a secure tunnel).  The daemon
does have "hosts allow" and "hosts deny" parameters.

> ssh: dont really want to have to put public private keys on systems to
> allow non interactive logons

I think ssh is the right approach.  I'm not sure whether you're
concerned about the risk of allowing the logins, the work of setting up
the keys, or both, so I'll address both concerns.

For the risk: You can use an ssh forced command to restrict the login to
invoking and accessing a particular "single-use" rsync daemon.  This
isn't fundamentally any more dangerous than having an rsync daemon
listening for connections as the same user.  To do this, write an
appropriate rsyncd.conf and set:

command="rsync --server --daemon --config=/PATH/TO/rsyncd.conf ."

on the authorized key in the user's ~/.ssh/authorized_keys .

For the setup work: If you want to allow noninteractive access from your
approved clients but not everyone else on the network, you will
inevitably have to give an authentication token of some sort to those
clients.  You could generate a single public/private key pair, put the
public key in the server user's authorized_keys file, give the private
key to every client, and have them pass it to ssh with the -i option
when they connect.  (As the incantation for clients to access the daemon
becomes more complex, you may wish to encapsulate it in a shell script
for easy distribution/updating; you can even include the key as a here
document.)

If you don't want to touch the server user's authorized_keys file, you
could have a separate user accept the ssh logins and either invoke the
daemon via setuid/sudo or connect to a background daemon on the same
machine (which works because the protocol is the same for single-use and
background daemons).

If you give me more specifics on your goals and requirements, I'll help
you find the best solution.

Matt