So, I'm using rssync now. Nice widget, I don't have to maintain my own
source tree for locally designed components (which is a big plus for
production environments), it's likely to remain compatible with rsync
updates due to its inclusion in the rsync source tarballs, and it does
a clean job of restricting access.
For casual user-account mirroring, it seems to work well with a
dedicated SSH key. This is particularly useful for software mirrors,
such as the sort of RPM build environments I've been working with
lately. Ideally, the target account for rsync access should *not* have
a valid shell. This reduces the risks of breaking out of the rrsync
command by a clever hacker: that's an old, old, old problem for script
based "shells", such as the "validate-rsync.sh" approach, and it
reduces potential rsync command confusion. In particular, when
mirroring the entire contents of a local directory to the top of a
designated mirror location, this command could be nasty if the access
is not restricted to the rrsync command:
rsync -avH --delete localdir/ user < at > servername:/
For root level access, it takes more thought. *especially* to avoid
precisely that little command problem I mentioned above. I've had a
look at a dedicated SSH daemon, with "ForceCommand" set and various
host based and key based restrictions. That allows tying host-specific
access to host-specific keys and IP addresses or client hostnames, and
one can even obtain the public keys of client hosts by using
"ssh-keygen" to scan for their SSH "host keys", and telling the
clients to use those root owned keys. And the clients can use their
host keys to then recover files, but with root only access. This also
allows me to restrict that sshd to root only access, but only for
designated hosts and the forced command, and disable other root SSH
access. If one *has* to allow root access to do this as a push, it
should be limited.
I can turn it around for a "pull" model and even use the built-in SSH
daemon, but it gets.... odder. Safer to use a separate daemon and
avoid mucking with the system SSH daemon.
One can get more restrictive by managing separate backup keys, but
that can get burdensome for clients who don't care to have their hosts
under central management, but do want to use the backup system.
*NOW* I've got a working local mirror that I can integrate rsnapshot
on top of. Thanks for the rrsync pointers, in particular.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
