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 [EMAIL PROTECTED]::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
.
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
