<div dir="ltr">The original request was to be able to copy files from local /etc to a remote /etc<br>while retaining file permissions (perms, owner, etc). This does require root on<br>the receiving box in some way.<br><br>Commenting on some previous suggestions:<br><br>* connecting to the remote system as a non-root user and giving it unrestricted<br>  'sudo rsync', which is invoked via --rsync-path='sudo rsync'. This can work<br>  only if you give sudo for only the exact specific rsync command that is<br>  generated on the server. If you simply allow 'sudo rsync' then an attacker<br>  on the client machine could trick it into running dangerous arguments.<br><br>* --super option: this makes rsync attempt to perform actions it doesn't think it<br>  can because the system isn't actually root. Unless you're doing some additional<br>  magic to provide the receiving user to be able to 'chown/etc' files it should<br>  not be able to (think kernel capabilities) then this won't work.<br><br><br>I do think the cleanest way would be to enable root ssh in /etc/ssh/sshd_config<br>and set up ssh key-based trust and restrict that key to an rsync wrapper that<br>validates the command.<br><br>The rrsync and sshdo wrappers are already described in this thread.<br><br>A third option is authprogs. It differs from the other options slightly:<br><br>rrsync: it can restrict download vs upload and directory, but no better granularity.<br><br>sshdo: learns commands but doesn't "understand them", so that's on you from both<div>a security and management standpoint. Main drawback in the rsync world is that when</div><div>rsync client starts sending equivalent(ish) but different looking server arguments you</div><div>will need to have it green light the new ones. For example 'rsync -v -v' and 'rsync -vv'</div><div>are equivalent, but look different enough that sshdo won't catch it.<div><div><br><br>Authprogs works differently in that it parses and groks the rsync command line options,</div><div>and rather than approving a specific command line you define the features you want to</div><div>allow or deny, and you configure your rules via a yaml file. It also offers the ability to restrict</div><div>commands based on other indicators such as key name and source IP.</div><div><br>Man page at <a href="https://github.com/daethnir/authprogs/blob/main/doc/authprogs.md">https://github.com/daethnir/authprogs/blob/main/doc/authprogs.md</a> and specifically<br>jump to the <a href="https://github.com/daethnir/authprogs/blob/main/doc/authprogs.md#rsync-subrules">rsync-subrules</a> section.<br><br><div><br></div><div>An example config for you:<br><br><font face="monospace">    # Allow rsync to recursively sync /etc/ to the server<br>    # in archive mode (-a, or any subset of -logptrD)<br>    # but do not allow download<br>    - <br>      from: [192.168.98.76, 192.168.54.32]<br>      allow:<br>        - rule_type: rsync<br>          allow_upload: true<br>          allow_recursive: true<br>          allow_archive: true<br>          paths:<br>            - /etc</font><br><br>Like sshdo you can use the same ssh key for multiple rsync commands which makes management<br>easier.<br><br>authprogs actually can run on the server and configure your ssh authorized_keys file for you<br><br>    <font face="monospace">authprogs --install_key id_rsa.pub</font><br><br>and it defaults to disabling a bunch of awesome but potentially dangerous ssh options like X11 forwarding.<br><br><br>If running via a direct root login is not an option I'd be happy to look at what changes authprogs<br>would need, if any, to work via 'sudo'. Both sshdo and authprogs would at a minimum need to have the<br><font face="monospace">SSH_ORIGINAL_COMMAND</font> environment variable exempted by sudo purging rules or be able to take these<br>as additional command line options.<br><br><br>As with any of these ssh-based options, protecting your client machine is critical because either you<br>have an ssh key unencrypted on disk (bad idea) or loaded into a local ssh-agent (still accessible to<br>any process running as that user or root, but cannot be exfiltrated to another machine by simply copying<br>the file, and unavailable at reboot.)<br></div></div></div></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 7, 2021 at 9:08 AM Chris Green via rsync <<a href="mailto:rsync@lists.samba.org">rsync@lists.samba.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Aug 07, 2021 at 08:10:47AM -0700, L A Walsh wrote:<br>
> On 2021/08/07 03:44, Chris Green via rsync wrote:<br>
> > L A Walsh via rsync <<a href="mailto:rsync@lists.samba.org" target="_blank">rsync@lists.samba.org</a>> wrote:<br>
> > > It seems to me, a safer bet would be to generate an ssh-cert<br>
> > > that allows a passwdless login from your sys to the remote.<br>
> > > <br>
> > The trouble with that is that it leaves a big security hole.<br>
> ----<br>
> <br>
>    If you only do backups at 1am (or whenever), why would your<br>
> backup machine enable ssh outside of the range 12:59 - 01:01?<br>
> <br>
Because cron/anacron isn't perfect and the machine being backed up nay<br>
not be turned on all the time so the time that it tries to backup is<br>
most definitely not fixed accurately!<br>
<br>
<br>
> > <br>
> > If (for example) I leave my laptop turned on somewhere, or someone<br>
> > wanders into my study where my desktop machine is they have instant,<br>
> > passwordless access to the remote backup machine.<br>
> ----<br>
>    If your desktop machine is that open to casual wanderers, perhaps<br>
> you should enable a passwd locked screen saver activating after a few<br>
> minutes?  I keep my home computer unlocked all the time as well, but I<br>
> don't have walk-through visitors that might mess with it.<br>
> <br>
Neither do I, though we do have family and friends around the place<br>
quite a lot.  I agree, in general, my desktop machine isn't<br>
particularly accessible or vulnerable but it *might* get hacked or<br>
accessed by an intruder and I thus try my best to protect the backup<br>
machine from it.<br>
<br>
> > I try very hard to make my backups secure from attack so that if my<br>
> > desktop or laptop is compromised somehow the (remote) backups are<br>
> > still secure.<br>
> ---<br>
>    Excellent!  In my case, my laptop/desktop (used to be a laptop) is<br>
> thoroughly entwined with the server such that one has trouble functioning<br>
> without the other.<br>
> <br>
>    In your case, though, I was thinking of a backup process that would<br>
> only be used when my laptop was on a secure network (like @ home).<br>
> <br>
Yes, but as above, if my laptop is compromised in any way (hopefully<br>
unlikely but still possible) I want my backups to be safe still.<br>
<br>
>    If there is risk to your laptop while @ home, hopefully it has a<br>
> short-timeout that bounces it to the screen saver that requires a<br>
> password to unlock?t<br>
> > <br>
> > The backup system that runs the rsync daemon has its rsync configured<br>
> > with 'refuse options = delete'<br>
> ---<br>
>    Ahh...I thought you were actually trying to keep them in sync.<br>
> Maybe you might think about using an actual backup prog like tar.<br>
> In my case, the Users/groups are the same.  Tar handles ext attrs and<br>
> acls and can keep track of backing files up that have actually changed<br>
> rather than relying on time/date stamps.<br>
> <br>
My *backups* of important data are incremental backups done once a day<br>
for every machine. I also do hourly incremental backups on my desktop<br>
machine but that is more for protecting myself against myself than for<br>
protecting against intruders or hardware failure.<br>
<br>
The original point of this thread is about something closer to<br>
synchronising my (small, Raspberry Pi) DNS server so that if it fails<br>
I can get a DNS server back up and running as quickly as possible.<br>
<br>
<br>
> >  so not only does someone with access to<br>
> > my desktop/laptop need to know the rsyncd username and password but<br>
> > they also cannot delete my existing backups.  It runs incremental<br>
> > backups so nothing is ever overwritten either.<br>
> ----<br>
>    BTW, incremental backups aren't really the same as 'update' backups,<br>
> they keep track of the state of the file system (including files no longer<br>
> there)<br>
> so you can restore your desktop to a specific day before some unwanted<br>
> updated was introduced and kept by an update-only backup system.<br>
> <br>
Yes, exactly, or more to the point (in my case anyway) I can restore a<br>
specific file to a few hours ago after I've scrambled it in some<br>
disastrous way! :-)<br>
<br>
I use the rsync --link-dest option to make the incremental backups<br>
(and, yes, I know this means that I only really have one copy of<br>
unchanging files.  I do have more than one backup)<br>
<br>
> Constructed it using rsync, but it really was too much work for<br>
> too little feature.<br>
> <br>
Mine too, as I said, is rsync with 'before the backup' and 'after the<br>
backup' python scripts that do the housekeeping like thinning out<br>
backups as they get older.<br>
<br>
-- <br>
Chris Green<br>
<br>
-- <br>
Please use reply-all for most replies to avoid omitting the mailing list.<br>
To unsubscribe or change options: <a href="https://lists.samba.org/mailman/listinfo/rsync" rel="noreferrer" target="_blank">https://lists.samba.org/mailman/listinfo/rsync</a><br>
Before posting, read: <a href="http://www.catb.org/~esr/faqs/smart-questions.html" rel="noreferrer" target="_blank">http://www.catb.org/~esr/faqs/smart-questions.html</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:12.8px">Bri Hatch, Systems and Security Engineer. <a href="http://www.ifokr.org/bri/" target="_blank">http://www.ifokr.org/bri/</a></span><br></div><div><br></div><div>The sooner you fall behind, the more time you'll have to catch up.</div><div><br></div></div></div>