On Fri, Jun 24, 2011 at 5:50 AM, Ruediger Meier <sweet_f_a < at > gmx.de> wrote:
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.
That's what the 'validate-rsync.sh' tool is designed for. It reviews
the designated ssh transmitted command, evaluates it for compliance
with the designated rsync commands, and if acceptable passes the
arguments to the "SSH_ORIGINAL_COMMAND", in this case the original
rsync command requested by the rsync client to the rsync server. It's
a cute widget and works well. What it lacks, for this case, is an
integrated parsing of the target directories tied to the incoming key
(or the host of the incoming connection, authorized with that key) and
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 /"
See above mentioned 'validate-rsync.sh' trick. That can even be used
for more sophisticated command restriction, it's just pesky to do in
more detail such as restricting the rsync target directory.
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.
And it opens your backup clients wide open to anyone who obtains the
central key, including material which the client systems may not wish
to transmit to the backup system. That's a noticeable potential issue.
It relies on the restraint of the central server to avoid backing up
inappropriate data to the shared backup pool, and forces configuration
updates to occur on the central server. That adds up to an issue in a
variegated environment. It also leaves scheduling in the hands of hte
clients, and *that* does not scale well.
It's not an uncommon setup, and there are plenty of environments where
it works well. I don't see this as one of them.
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.
That's above. I'd love to isolate the operation further from the base
OS of the server, with rsync incorporated, and keep the target backup
directories for each client separate from the other clients. That's
triickier, and significant work. I'd hate to slap together something
makeshift and long-term unstable, I've seen way too many such
solutions over the years.
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.
You ever tried that stunt? It's..... tricky. It seems feasible with a
directory full of "validate-rsync" scripts, one for each client host,
but running those all as root..... hmmmm. Let me think about that one.
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.
That's at risk of race conditions and resulting discrepancies between
the file transmission and the metastore ansmission. Not inconceivable
for basic recovery purposes, but a potential issue for edge cases. I'd
need to think about whether that is good enough
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
It *is* an interesting thought! The metastore information would need a
secure transmission, and there are those synchronization issues. The
underlying problem is porting metastore around to all the client
systems. I can guarantee the presence and compatibility of "rsync",
but not of metastore on the variety of platforms.
------------------------------------------------------------------------------
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
