[TriLUG] rsyncd.conf

[Jason Tower]

i use rsyncd from time to time, it's pretty slick and avoids the problem 
you describe (there's no shell access or key exchange required).  i 
missed the first part of this thread, but here's an example of one of my 
"shares":

[company_xyz]
   path = /home/rsync/company_xyz
   secrets file = /etc/rsyncd.secrets
   auth users = company_xyz
   use chroot = yes
   list = no
   read only = no
   uid = root

note that it looks very much like a samba share, probably because the 
same guy wrote it (http://samba.org/~tridge/).  client access is 
chrooted, but it does run as root (needed to preserve file ownership, if 
you don't care about that it can run as a normal user).

the rsyncd.secrets file contains the following line:

   company_xyz:some_password

on the remote host, i have a cron job that contains one or more lines 
like the following:

   rsync -avz /data_files company_xyz at cerient.net::company_xyz \
   --numeric-ids --password-file=/root/rsync.passwd --delete

the only real weakness with this approach is security.  from the rsyncd 
help page:

"The authentication protocol used in rsync is a 128 bit MD4 based 
challenge response system. Although I believe that no one has ever 
demonstrated a brute-force break of this sort of system you should 
realize that this is not a "military strength" authentication system. It 
should be good enough for most purposes but if you want really top 
quality security then I recommend that you run rsync over ssh.

Also note that the rsync server protocol does not currently provide any 
encryption of the data that is transferred over the link. Only 
authentication is provided. Use ssh as the transport if you want 
encryption."

hope this helps...jason

Alan Porter wrote:
> 
>> That's what PUBLIC keys are for, it's the private keys you want to
>> keep secret, without one the other is worthless.
>>  
>>
> 
> In that case, let me give you my public key, and you add
> it to YOUR /root/.ssh/authorized_keys file!
> 
> What I am trying to prevent is the "keys to the kingdom"
> problem, where someone who has cracked the backup
> box suddenly has root access to all machines on the
> network.  (Keeping in mind, of course, that if they've
> cracked the backup box, they already have a copy of
> everyone's data).
> 
> Meanwhile, I like your sudo idea.  The backup user has
> permission to do nothing except run the rsync script.
> 
> This gives me something to play with.  It's not quite as
> tidy as the rsyncd approach, but: (1) create a backup user
> (2) make sure your script is non-writable (3) give the user
> sudo access to the script and (4) plant the server's public
> key in his AK file.  And that sounds like it'll work.
> 
> 
> So no one uses rsyncd?  I know that ssh is the Swiss
> Army knife of the modern world, but still...
> 
> 
> Alan
> 
> 
> 
> 
> 
> .
>