What I do is allow root key's but use a single purpose key that runs rsync in a specific directory. Same end result as chrooting but I can maintain permissions.<br><br><div class="gmail_quote">On Fri, Nov 4, 2011 at 9:12 AM, marcus hall <span dir="ltr"><<a href="mailto:marcus@tuells.org">marcus@tuells.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Thu, Nov 3, 2011 at 7:51 PM, Jason Friedman <<a href="mailto:jason@powerpull.net">jason@powerpull.net</a>> wrote:<br>
<br>
> I am wanting to synchronize two filesystems, probably with rsync, and<br>
</div>...<br>
<div class="im">> For root to connect to another host as root, absent someone typing a<br>
> password, SSH keys could be exchanged, or one can use RSH and .rhosts<br>
> (unencrypted).<br>
> If my organization discourages the use of RSH and discourages the use<br>
> of exchanging root's keys (but accepts the exchanging of non-root<br>
> keys), what are my options?<br>
<br>
</div><div class="im">On Thu, Nov 03, 2011 at 08:31:08PM -0600, Will wrote:<br>
> Use single purpose SSH keys, connect as a non-root user with an autharized<br>
> key. When that key is used it runs sudo and starts rsync as root.<br>
<br>
</div>Of course, exchanging keys of a non-root user that can sudo rsync is<br>
essentially the same thing as exchanging keys of root, so this is getting<br>
around the letter of the policy while violating the spirit of the policy.<br>
<br>
What you need to do is to restrict the scope of what rsync can overwrite,<br>
perhaps building a chroot environment or something, and restricting the<br>
ssh user to only be able to execute the command to get into the environment<br>
(which may invlove sudo along the way). Also, I think you can restrict<br>
the connection to be from the appropriate client system as well.. These<br>
are all good to prevent spread of a compromise.<br>
<br>
Without such restrictions, if the public key of the client system (the<br>
one that initiates the connection) is compromised, then someone could<br>
use the root-priviledged rsync could overwrite any file on the server<br>
that they desired...<br>
<br>
If the contents of the directory can be changed on either machine, then<br>
the problem of keeping them in sync is more problematic. Rsync can take<br>
a whack at it (check out the -u option to update only if the file is<br>
newer), but it fails to properly handle conflicts and deletions. A better<br>
tool for this is unison, which is designed to handle this. If you are<br>
keeping a backup, then rdiff-backup is based on librsync, but does other<br>
things useful for backup, like maintaining previous versions, etc.<br>
<span class="HOEnZb"><font color="#888888"><br>
marcus hall<br>
<a href="mailto:marcus@tuells.org">marcus@tuells.org</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
clue mailing list: <a href="mailto:clue@cluedenver.org">clue@cluedenver.org</a><br>
For information, account preferences, or to unsubscribe see:<br>
<a href="http://cluedenver.org/mailman/listinfo/clue" target="_blank">http://cluedenver.org/mailman/listinfo/clue</a><br>
</div></div></blockquote></div><br>