rsync support in authprogs - feedback requested
bri at ifokr.org
Thu Feb 18 17:47:01 UTC 2021
I'm aware of rrsync, and it works well for its use case.
We use authprogs for more than just rsync though, and want more granularity
than rrsync can support. If you force rrsync for the ssh key via
command="rrsync" then that key may only be used to run rsync, you can't
also allow additional commands. From a CI/CD perspective it may be useful
to have the client side rsync some files, restart some services, and not
need to use separate keys for each.
Additionally, we'd like to be able to limit some of the feature flags (e.g.
allow/disallow links), or support multiple paths (/opt/pkgs/somedir/ and
/srv/someotherdir) without making separate ssh identities and
authorized_keys entries for each.
On Thu, Feb 18, 2021 at 9:22 AM Kevin Korb via rsync <rsync at lists.samba.org>
> You should both look into rrsync. It comes with rsync and is designed
> to do exactly this. Unfortunately some Linux distros are maintained by
> insane people who install rrsync as if it was documentation (compressed
> and not executable) instead of a helper script which is what it is.
> On 2/18/21 10:28 AM, Karl O. Pinc via rsync wrote:
> > On Wed, 17 Feb 2021 21:52:06 -0800
> > Bri Hatch via rsync <rsync at lists.samba.org> wrote:
> >> I recently added initial rsync support to authprogs.
> >> I'd be very interested in feedback
> > For some 15 years+ (?) I've had a /root/.ssh/authorized keys line
> > that starts with:
> --server --daemon ."
> > Occasionally I frob the ssh restrictions as new ones are
> > introduced.
> > The remote end uses rsync to backup (with --link-dest) the
> > entire file system. The idea (iirc) was to restrict
> > the given key so that it would only run rsync.
> > And I think this also forces the local end to use
> > /etc/rsyncd.conf, where there's an additional layer
> > of security via a secrets file and read-only can
> > be set to provide some control.
> > The remote end always runs rsync -- the direction of
> > transfer is static, per-host-pair, but can be either
> > in or out. (Push or pull backups.) The above authorized_keys
> > line does not enforce direction, which might be useful.
> > I only rarely think about tweaking the authorized_keys line,
> > and the rsync options used haven't changed since I got them to work.
> > Without really thinking about it it seems that your
> > authprogs development might be useful.
> > My purpose with this email is to let you do all the
> > thinking and tell me of all the wonderful utility
> > your authprogs work can provides, either now or
> > in the future. ;-) Or at least give you some
> > background in case you want to develop in a direction
> > that you think would helpful to me. If something comes
> > of this I might even turn my brain on again and
> > modify my systems. :)
> > Regards,
> > Karl <kop at karlpinc.com>
> > Free Software: "You don't pay back, you pay forward."
> > -- Robert A. Heinlein
> Kevin Korb Phone: (407) 252-6853
> Systems Administrator Internet:
> FutureQuest, Inc. Kevin at FutureQuest.net (work)
> Orlando, Florida kmk at sanitarium.net (personal)
> Web page: https://sanitarium.net/
> PGP public key available on web site.
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe or change options:
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Bri Hatch, Systems and Security Engineer. http://www.ifokr.org/bri/
The sooner you fall behind, the more time you'll have to catch up.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rsync