On Friday 24 June 2011, Nico Kadel-Garcia wrote:
I'm back, I'm back. (Been quiet for years.)
I'm looking at an environment of roughly 100 boxes, all to back up to
an rsnapshot server. I'm very familiar with rsnapshot, but can't
necessarily get the owners of the boxes to allow me to install an SSH
key with root access, even wrapping the key in a 'validate-rsync.sh'
setup to assure it is used only for rsync.
If you are speaking about 'command="bla" key...' statement in
~/.ssh/authorized_keys. That's a per key definition. Anybody who tries
to login using that key will always execute command "bla". Doesn't
matter which client is used.
I'm using rrsync as allowed command which comes with rsync source code
and is mentioned in man rsync.
In my setup I don't push but pull the backup. This way I can restrict
the rsync login from backup server on the client readonly:
command="/usr/local/bin/rrsync -ro /"
Pulling the backup makes you able to harden your backup host which is
probably your most important one. Of course there are also some good
reasons to push instead.
If you want to push you would need something like
command="/usr/local/bin/rrsync -rw /path/to/clientX"
for each client.
Could be that it's possible somehow to run rrsync script (or even the
whole sshd) in a chroot.
But maybe this would be also nice even without chroot:
If you dont't trust rrsync being executed as root and having authorized
keys defined for root all then you could use a non-privileged user for
login and just giving him sudo permissions for the final rsync command
and the end of rrsync script.
So you have to trust only the correctness of the local rsync process.
I've used that before very effectively, but it does leave packet
sniffing of the rsync protocol quite feasible. If I install SSH keys
for the clients to push to the server, then *THOSE* need root access,
and I've got to contain *those*.somehow.
You need root access only to keep file ownership and permissions
directly within the target file system right?
Did you considered to push backups to a non-root user and saving the
original file stats separately? For example you could run metastore on
client before backup starts. Then just inlude the resulting file within
the backup.
Benefit: You wouldn't have any bad suid file etc. of a bad client on the
backup host. Stats needs only to be reapplied if you _need_ the backup.
http://david.hardeman.nu/software.php#metastore
cu,
Rudi
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
