Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Felix Wolters]

> In fact, my 'sudo' approach worked so well …
Then, how do you restrict access to certain paths in your setups?

Am 11.02.21 um 01:58 schrieb backu...@kosowsky.org:
> Felix Wolters wrote at about 00:14:37 +0100 on Thursday, February 11, 2021:
>  > Jeff,
>  > 
>  > I appreciate your detailled discussion of the topic, and I consider your
>  > arguments to be strong.
>  > 
>  > But this …
>  > 
>  > > Finally, while the sudoer code I shared in my previous note was just
>  > > aimed at restricting the sudoer power to rsync with specific flags, 
>  > > I'm pretty sure that it could be easily expanded to
>  > > also limit access to only certain files/directories but just extending
>  > > the sudoer line to add the paths desired, thereby further restricting
>  > > the reach of the sudo command allowed.
>  > seems to be the critical point to me. Have your tried that? (I haven’t
>  > yet; a quick search at least doesn’t show up manifestations of this
>  > approach.)
>
> I'm not sure anyone else has done the detailed specific sudoer approach that I
> use for backuppc so not surprised it's not documented :)
>
> I'm pretty confident the approach will work to restrict files as you
> can verify using 'ps' what the full command line is... Just run 'ps
> aux | grep rsync' when you are running a backup...
>
> In fact, my 'sudo' approach worked so well that I was stumped when
> backuppc stopped working when I upgraded my rsync version and it
> stopped working -- only after much flailing, did I realize that for
> rsync >=3.1.x, two new command line parameters ('xC') were added.
>
> Remember ultimately both approaches are trying to do the same thing by
> restricting the command lines that can be executed -- but as I laid
> out, I think 'normal user escalated with limited sudo' is safer than
> 'root user restricted by combination of ssh option plus perl plus perl
> app of unknown hardness'
>
> I should also point out that there are many subtleties and
> vulnerabilities to the command restriction approach that can introduce
> security issues. For example, you need to protect against shell
> extensions and escapes (as a trivial example, if you allow '&&' then you can
> add an arbitrary command) as well as path changes etc.
>
> The sudo people have had years to weed out such vulnerabilities. I
> have no idea how well rrsync's developer has tested against all types
> of malicious command line manipulations.
>
>
>  > > At the end of the day, with rrsync, you are still allowing root
>  > >access to ssh and that just doesn't feel right.
>  > Well … any time you administrate a remote machine, you gain root access
>  > over ssh to it, so this alone is a danger we use to deal with. On the
>  > other hand, with the rsync-via-sudoers approach – don’t we open rsync to
>  > the full system, so basically an attacker on the currupted server would
>  > be able to basically rsync the whole machine to himself? So, at the end
>  > of the day, aren’t we trading a potential security vulnerability
>  > (rrsync) with a heavy real one (rsync via sudoers)?
>  > 
>  > 
>  > Am 10.02.21 um 20:59 schrieb backu...@kosowsky.org:
>  > > Felix Wolters wrote at about 19:45:49 +0100 on Wednesday, February 10, 
> 2021:
>  > >  > Greg,
>  > >  > 
>  > >  > Yupp, that’s the principle, especially refer to the paragraph
>  > >  > 
> https://dev-notes.eu/2016/08/secure-rsync-between-servers/#limit-actions-for-this-ssh-connection-to-restricted-rsync
>  > >  > 
>  > >  > I can recommend it so far.
>  > >  > 
>  > >  > I may add, that working with a non-privieged user isn’t even necessary
>  > >  > in many cases, as rrsync is able to restrict access to (1.) a specific
>  > >  > command (if need be with specific options), (2.) a specific folder, 
> and
>  > >  > (3.) to read only access – but offer full root access and allowing 
> rsync
>  > >  > -a to keep users, groups and permissions. That makes it powerful.
>  > >
>  > > See my earlier note on my concerns about the relative security of this
>  > > method vs. ssh to a restricted remote user plus a well-constructed
>  > > sudoer line to elevate only the specific command needed to backup your 
> files/directories.
>  > >
>  > >  > The problem here just seems to be that rrsync (on the client to back 
> up)
>  > >  > and rsync-bpc are not compatible, and a patched rrsync will – 
> hopefully!
>  > >  > – be the solution.
>  > >
>  > >
>  > > ___
>  > > BackupPC-users mailing list
>  > > BackupPC-users@lists.sourceforge.net
>  > > List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
>  > > Wiki:https://github.com/backuppc/backuppc/wiki
>  > > Project: https://backuppc.github.io/backuppc/
>  > 
>  > 
>  > ___
>  > BackupPC-users mailing list
>  > BackupPC-users@lists.sourceforge.net
>  > List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
>  > Wiki:https://github.com/backuppc/backuppc/wiki
>  

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

Felix Wolters wrote at about 00:14:37 +0100 on Thursday, February 11, 2021:
 > Jeff,
 > 
 > I appreciate your detailled discussion of the topic, and I consider your
 > arguments to be strong.
 > 
 > But this …
 > 
 > > Finally, while the sudoer code I shared in my previous note was just
 > > aimed at restricting the sudoer power to rsync with specific flags, 
 > > I'm pretty sure that it could be easily expanded to
 > > also limit access to only certain files/directories but just extending
 > > the sudoer line to add the paths desired, thereby further restricting
 > > the reach of the sudo command allowed.
 > seems to be the critical point to me. Have your tried that? (I haven’t
 > yet; a quick search at least doesn’t show up manifestations of this
 > approach.)

I'm not sure anyone else has done the detailed specific sudoer approach that I
use for backuppc so not surprised it's not documented :)

I'm pretty confident the approach will work to restrict files as you
can verify using 'ps' what the full command line is... Just run 'ps
aux | grep rsync' when you are running a backup...

In fact, my 'sudo' approach worked so well that I was stumped when
backuppc stopped working when I upgraded my rsync version and it
stopped working -- only after much flailing, did I realize that for
rsync >=3.1.x, two new command line parameters ('xC') were added.

Remember ultimately both approaches are trying to do the same thing by
restricting the command lines that can be executed -- but as I laid
out, I think 'normal user escalated with limited sudo' is safer than
'root user restricted by combination of ssh option plus perl plus perl
app of unknown hardness'

I should also point out that there are many subtleties and
vulnerabilities to the command restriction approach that can introduce
security issues. For example, you need to protect against shell
extensions and escapes (as a trivial example, if you allow '&&' then you can
add an arbitrary command) as well as path changes etc.

The sudo people have had years to weed out such vulnerabilities. I
have no idea how well rrsync's developer has tested against all types
of malicious command line manipulations.


> 
 > > At the end of the day, with rrsync, you are still allowing root
 > >access to ssh and that just doesn't feel right.
 > Well … any time you administrate a remote machine, you gain root access
 > over ssh to it, so this alone is a danger we use to deal with. On the
 > other hand, with the rsync-via-sudoers approach – don’t we open rsync to
 > the full system, so basically an attacker on the currupted server would
 > be able to basically rsync the whole machine to himself? So, at the end
 > of the day, aren’t we trading a potential security vulnerability
 > (rrsync) with a heavy real one (rsync via sudoers)?
 > 
 > 
 > Am 10.02.21 um 20:59 schrieb backu...@kosowsky.org:
 > > Felix Wolters wrote at about 19:45:49 +0100 on Wednesday, February 10, 
 > > 2021:
 > >  > Greg,
 > >  > 
 > >  > Yupp, that’s the principle, especially refer to the paragraph
 > >  > 
 > > https://dev-notes.eu/2016/08/secure-rsync-between-servers/#limit-actions-for-this-ssh-connection-to-restricted-rsync
 > >  > 
 > >  > I can recommend it so far.
 > >  > 
 > >  > I may add, that working with a non-privieged user isn’t even necessary
 > >  > in many cases, as rrsync is able to restrict access to (1.) a specific
 > >  > command (if need be with specific options), (2.) a specific folder, and
 > >  > (3.) to read only access – but offer full root access and allowing rsync
 > >  > -a to keep users, groups and permissions. That makes it powerful.
 > >
 > > See my earlier note on my concerns about the relative security of this
 > > method vs. ssh to a restricted remote user plus a well-constructed
 > > sudoer line to elevate only the specific command needed to backup your 
 > > files/directories.
 > >
 > >  > The problem here just seems to be that rrsync (on the client to back up)
 > >  > and rsync-bpc are not compatible, and a patched rrsync will – hopefully!
 > >  > – be the solution.
 > >
 > >
 > > ___
 > > BackupPC-users mailing list
 > > BackupPC-users@lists.sourceforge.net
 > > List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
 > > Wiki:https://github.com/backuppc/backuppc/wiki
 > > Project: https://backuppc.github.io/backuppc/
 > 
 > 
 > ___
 > BackupPC-users mailing list
 > BackupPC-users@lists.sourceforge.net
 > List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
 > Wiki:https://github.com/backuppc/backuppc/wiki
 > Project: https://backuppc.github.io/backuppc/


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Guillermo Rozas]

Sorry, it seems the base version of rrsync I used is quite old compared to
the current one, and I can't pinpoint which modifications are mine and
which are 'upstream'. All I can say is that:

- the attached version works with BackupPC 4.3.2, using the following
command line in the client's authorized_keys:

command="$HOME/.bin/rrsync_bkpc -ro
/path/to/backup",from="192.168.1.2",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding

- I vaguely remember having added and/or modified the allowed options for
rsync in the rrsync script (lines 55 to 139). If there is more than that, I
don't remember

I hope this helps. Best regards,
Guillermo

PS: I don't use sudo or root, BackupPC connects as the (only) non-root user
of the client using rrsync, restricted to the folder I want to backup
(basically the user's home, so there is no need for root access). Even if
rrsync is compromised, the remote has no way to gain root access as there
is no passwordless sudo configured in the machines.

On Wed, Feb 10, 2021 at 10:51 AM Felix Wolters 
wrote:

> Thank you, Guillermo in advance, this will be great!
>
> Felix
>
>
> Am 10.02.21 um 14:01 schrieb Guillermo Rozas:
>
> Hi,
> I use rrsync in a couple of clients. You need to slightly modify the
> rrsync script to correctly parse BackupPC rsync call, and after that it
> will work without problems. Later in the week I'll look into my systems and
> post my rrsync modified version.
> Regards,
> Guillermo
>
> On Tue, Feb 9, 2021, 13:11 Felix Wolters  wrote:
>
>> Hello!
>>
>> Let me first thank you for providing BackupPC as open source software. I
>> appreciate it a lot and consider it to be one of the most usefull backup
>> systems out there!
>>
>> I’d like to use it with restricted access to the client, so a
>> potentially corrupted BackupPC server wouldn’t be able to damage the
>> client machine and data. Using rsync for transfer with a Linux client,
>> rrsync (restricted rsync – as part of the rsync package) would be a
>> straigt forward solution to restrict an incoming ssh connection to only
>> rsync and only a given folder which I will set read only – which would
>> perfectly do the trick. Unfortunately, this doesn’t seem to work with
>> BackupPC over rsync, as far as I can see. I’m positive rrsync generally
>> works on the client as I use it successfully with plain rsync over ssh
>> on the same machine.
>>
>> I’ve seen rare information on the internet about this, and it wouldn’t
>> help me so far.
>>
>> Thank you for some help or instruction!
>>
>> Best
>>
>>
>>
>> ___
>> BackupPC-users mailing list
>> BackupPC-users@lists.sourceforge.net
>> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
>> Wiki:https://github.com/backuppc/backuppc/wiki
>> Project: https://backuppc.github.io/backuppc/
>>
>
>
> ___
> BackupPC-users mailing listbackuppc-us...@lists.sourceforge.net
> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:https://github.com/backuppc/backuppc/wiki
> Project: https://backuppc.github.io/backuppc/
>
> ___
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:https://github.com/backuppc/backuppc/wiki
> Project: https://backuppc.github.io/backuppc/
>


rrsync_bkpc_mod
Description: Binary data
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Adam Goryachev via BackupPC-users]

On 11/2/21 10:14, Felix Wolters wrote:

Jeff,

I appreciate your detailled discussion of the topic, and I consider your
arguments to be strong.

But this …


Finally, while the sudoer code I shared in my previous note was just
aimed at restricting the sudoer power to rsync with specific flags,
I'm pretty sure that it could be easily expanded to
also limit access to only certain files/directories but just extending
the sudoer line to add the paths desired, thereby further restricting
the reach of the sudo command allowed.

seems to be the critical point to me. Have your tried that? (I haven’t
yet; a quick search at least doesn’t show up manifestations of this
approach.)


At the end of the day, with rrsync, you are still allowing root
access to ssh and that just doesn't feel right.

Well … any time you administrate a remote machine, you gain root access
over ssh to it, so this alone is a danger we use to deal with. On the
other hand, with the rsync-via-sudoers approach – don’t we open rsync to
the full system, so basically an attacker on the currupted server would
be able to basically rsync the whole machine to himself? So, at the end
of the day, aren’t we trading a potential security vulnerability
(rrsync) with a heavy real one (rsync via sudoers)?


It seems that both approaches are adding some security, some of that 
security is overlapping, and some is unique to each approach. If you 
really want to protect as much as possible, why not use both? Have a 
non-root user call sudo which calls rrsync


Based on my minimal understanding that rrsync is simply a script which 
checks the arguments given to the real rsync before calling it.


PPS, also keep in mind that avoiding sudo avoids security complications 
in sudo, as avoiding rrsync avoids potential security bugs in rrsync 
(eg, the ability to exploit argument processing to get remote code 
execution) both of which might have been protected with plain rsync and 
ssh alone.


Just my 0.02c



___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Felix Wolters]

Jeff,

I appreciate your detailled discussion of the topic, and I consider your
arguments to be strong.

But this …

> Finally, while the sudoer code I shared in my previous note was just
> aimed at restricting the sudoer power to rsync with specific flags, 
> I'm pretty sure that it could be easily expanded to
> also limit access to only certain files/directories but just extending
> the sudoer line to add the paths desired, thereby further restricting
> the reach of the sudo command allowed.
seems to be the critical point to me. Have your tried that? (I haven’t
yet; a quick search at least doesn’t show up manifestations of this
approach.)

> At the end of the day, with rrsync, you are still allowing root
>access to ssh and that just doesn't feel right.
Well … any time you administrate a remote machine, you gain root access
over ssh to it, so this alone is a danger we use to deal with. On the
other hand, with the rsync-via-sudoers approach – don’t we open rsync to
the full system, so basically an attacker on the currupted server would
be able to basically rsync the whole machine to himself? So, at the end
of the day, aren’t we trading a potential security vulnerability
(rrsync) with a heavy real one (rsync via sudoers)?


Am 10.02.21 um 20:59 schrieb backu...@kosowsky.org:
> Felix Wolters wrote at about 19:45:49 +0100 on Wednesday, February 10, 2021:
>  > Greg,
>  > 
>  > Yupp, that’s the principle, especially refer to the paragraph
>  > 
> https://dev-notes.eu/2016/08/secure-rsync-between-servers/#limit-actions-for-this-ssh-connection-to-restricted-rsync
>  > 
>  > I can recommend it so far.
>  > 
>  > I may add, that working with a non-privieged user isn’t even necessary
>  > in many cases, as rrsync is able to restrict access to (1.) a specific
>  > command (if need be with specific options), (2.) a specific folder, and
>  > (3.) to read only access – but offer full root access and allowing rsync
>  > -a to keep users, groups and permissions. That makes it powerful.
>
> See my earlier note on my concerns about the relative security of this
> method vs. ssh to a restricted remote user plus a well-constructed
> sudoer line to elevate only the specific command needed to backup your 
> files/directories.
>
>  > The problem here just seems to be that rrsync (on the client to back up)
>  > and rsync-bpc are not compatible, and a patched rrsync will – hopefully!
>  > – be the solution.
>
>
> ___
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:https://github.com/backuppc/backuppc/wiki
> Project: https://backuppc.github.io/backuppc/


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[backuppc]

Les Mikesell wrote at about 14:07:23 -0600 on Wednesday, February 10, 2021:
 > On Wed, Feb 10, 2021 at 1:58 PM  wrote:
 > >
 > > 4. Further, along that line, while sudoer has been well-tested,
 > 
 > About that
 >   https://www.helpnetsecurity.com/2021/01/27/cve-2021-3156/
 > 

Thanks for supporting my contention that 'sudo' is actively and
continually tested, patched and improved.
The fact that the community continues to actively search for
vulnerabilities and then patch them gives me infinitely more
confidence in sudo than in untested or undertested approaches.

Has anybody done a security review of rrsync?? (along with how it
interacts with perl, perl libraries, ssh and the authorized_keys file,
etc.)

Again thanks Les for the helpful real-life proof-point!


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Les Mikesell]

On Wed, Feb 10, 2021 at 1:58 PM  wrote:
>
> 4. Further, along that line, while sudoer has been well-tested,

About that
  https://www.helpnetsecurity.com/2021/01/27/cve-2021-3156/

-- 
   Les Mikesell
 lesmikes...@gmail.com


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[backuppc]

Felix Wolters wrote at about 19:45:49 +0100 on Wednesday, February 10, 2021:
 > Greg,
 > 
 > Yupp, that’s the principle, especially refer to the paragraph
 > https://dev-notes.eu/2016/08/secure-rsync-between-servers/#limit-actions-for-this-ssh-connection-to-restricted-rsync
 > 
 > I can recommend it so far.
 > 
 > I may add, that working with a non-privieged user isn’t even necessary
 > in many cases, as rrsync is able to restrict access to (1.) a specific
 > command (if need be with specific options), (2.) a specific folder, and
 > (3.) to read only access – but offer full root access and allowing rsync
 > -a to keep users, groups and permissions. That makes it powerful.

See my earlier note on my concerns about the relative security of this
method vs. ssh to a restricted remote user plus a well-constructed
sudoer line to elevate only the specific command needed to backup your 
files/directories.

> 
 > The problem here just seems to be that rrsync (on the client to back up)
 > and rsync-bpc are not compatible, and a patched rrsync will – hopefully!
 > – be the solution.


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[backuppc]

Les Mikesell wrote at about 13:05:40 -0600 on Wednesday, February 10, 2021:
 > On Wed, Feb 10, 2021 at 12:47 PM Felix Wolters  
 > wrote:
 > >
 > > I may add, that working with a non-privieged user isn’t even necessary in 
 > > many cases, as rrsync is able to restrict access to (1.) a specific 
 > > command (if need be with specific options), (2.) a specific folder, and 
 > > (3.) to read only access – but offer full root access and allowing rsync 
 > > -a to keep users, groups and permissions. That makes it powerful.
 > >
 > > The problem here just seems to be that rrsync (on the client to back up) 
 > > and rsync-bpc are not compatible, and a patched rrsync will – hopefully! – 
 > > be the solution.
 > 
 > Isn't rrsync just a perl wrapper to start rsync but ensure it is only
 > accessing a permitted subdirectory?  If so it should be a matter of
 > tweaking the command to start it to be compatible.

Yes - I just looked it up...
See: http://biplane.com.au/blog/?p=591

Basically it seems like rrsync doesn't do much more than use the ssh
forced (restriced) command functionality, where the commands run by
ssh are limited by adding "command=rrsync..." to the authorized keys
file (which itself is bad as one should use the full path in the
command).

Based on this, the way to fix rrsync to be rsync-backuppc compatible
is probably embedded in my previous note where in my sudoers file I
have abstracted the exact rsync command and arguments that rsync-bpc
invokes on the remote host.

Indeed, I believe that my solution with sudo is likely better/more
secure than rrsync for multiple reasons:

1. Rather than allowing root ssh and then restricting access to some
   commands, I only allow ssh to a non-root user and only elevate a
   specific command. This intuitively seems to be more secure than
   trying to handcuff a root login as my login user is never root.

2. Furthermore, if you have an ssh-agent or if you inadvertently
   change your authorized_keys file, you will expose full root
   capabilities while it is much less likely that you will
   inadvertently change your sudoer file to expand access.

3. In general, sudoer offers more fine-grained control over access as
   that is what it was designed and hardened to do -- while the rrsync
   approach relies on a generic and pretty blunt ssh feature.

4. Further, along that line, while sudoer has been well-tested, I'm
   not sure how well tested the perl rrsync code is for security and
   vulnerabilities in whatever libraries it may use. We all hopefully
   remember the past issues with trying to harden perl to allow sudo
   perl scripts. Vulnerabilities are possible in not just perl itself
   but in any library called by rrsync.

5. At the end of the day, with rrsync, you are still allowing root
   access to ssh and that just doesn't feel right. And a breach in
   security may be harder to distinguish as it shows up as a root
   user. In my approach, the only user that ever logs on to your
   remote host is a limited user -- which can easily be seen and
   logged -- and distinguished from a generic root user.

Finally, while the sudoer code I shared in my previous note was just
aimed at restricting the sudoer power to rsync with specific flags, 
I'm pretty sure that it could be easily expanded to
also limit access to only certain files/directories but just extending
the sudoer line to add the paths desired, thereby further restricting
the reach of the sudo command allowed.

Best of all my approach does not require adding and maintaining a new
program (rrsync) along with the burden of installing perl on the remote
host.

Now all I need is Craig to tweak the construction of the
$Conf{RsyncClientPath} variable so that I don't have to use an awful
kluge to allow "/usr/bin/sudo /usr/bin/rsync" as the remote rsync
command...

Jeff



___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[backuppc]

G.W. Haywood via BackupPC-users wrote at about 16:10:03 + on Wednesday, 
February 10, 2021:
 > Hi there,
 > 
 > On Wed, 10 Feb 2021, Felix Wolters wrote:
 > 
 > > I'd like to use it with restricted access to the client ...
 > 
 > If I understand you correctly there's no need for complications, you
 > can do that with plain vanilla rsyncd.  It's what I do on my machines.
 > Forbidding ssh access further reduces the attackable surface.
 > 

Rsyncd is of course less secure in many ways than rsync over ssh.
Specifically, it uses a clear text password stored in
/etc/rsyncd.secrets.
Second, the transfers are not encrypted in flight unless you kludge an
additional transport layer beneath backuppc.
Finally, rsyncd requires special setup and configuration on each
client in order to determine what to backup up in addition to doing so
in /etc/backuppc/pc/host.pl

That being said, I used to use rsyncd when I was playing with backuppc on
an old underpowered plugcomputer to backup old Windows computers where
the overhead of ssh encryption made rsyncd significantly faster than
rsync.

Jeff


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[backuppc]

As a poor man's protection, when backing up Linux hosts, I avoid
ssh'ing into root@remotehost and instead ssh into a non-admin user
backupp-remote and then use /etc/sudoer to limit the superuser reach
to /usr/bin/rsync with selected flags. Of course, this still leaves
security holes to a malicious hacker but it does create some
restrictions.

In my config file, I use:
   $Conf{RsyncClientPath} = '/usr/bin/sudo /usr/bin/rsync';
   $Conf{RsyncSshArgs} = ['-e', '$sshPath -l backuppc-remote'];
   #Note: above kluge generates rsync statement on the *remote* host of form:
   # /usr/bin/ssh -l backuppc-remote  /usr/bin/sudo /usr/bin/rsync 
--server --sender -slHogDtpAXrcxe.iLsf --iconv=UTF-8

In my /etc/sudoers file, I use:
   #: BackupPC
   #: Don't require tty for backuppc, backuppc-remote
   Defaults:backuppc,backuppc-remote !requiretty
   #: Allow user backuppc & backuppc-remote to run sudo rsync to avoid need for 
ssh root@localhost:
   #: Note for rsync < 3.1.x, string to sender can be either: 
-slHogDtpAXrcxe.iLsf (full) or -slHogDtpAXrxe.iLsf (incremental)
   backuppc,backuppc-remoteALL=NOPASSWD: /usr/bin/rsync --server 
--sender -slHogDtpAXrxe.iLsf, /usr/bin/rsync --server --sender 
-slHogDtpAXrcxe.iLsf
   #: Note for rsync >= 3.1.x, string to sender can be either: 
-slHogDtpAXrcxe.iLsfxC (full) or -slHogDtpAXrxe.iLsfxC (incremental)
   backuppc,backuppc-remote   ALL=NOPASSWD: /usr/bin/rsync --server 
--sender -slHogDtpAXrxe.iLsfxC, /usr/bin/rsync --server --sender 
-slHogDtpAXrcxe.iLsfxC

And my passwd file is setup as follows:
backuppc-remote:x:1200:1200:Backuppc user for remotely backing up this 
host:/home/backuppc-remote:/bin/sh

Felix Wolters wrote at about 17:14:43 +0100 on Wednesday, February 10, 2021:
 > Just to clarify: My question is about using rrsync on the remote client
 > to protect it (as I explained) from a potentially currupted server.
 > Obviously, the standard rrsync isn’t compatible with rsync-bpc. So I’m
 > curious about Guillermo’s adjusted version of rrsync!
 > 
 > What I did got so far:
 > 
 >   * BackupPC works without any problem with standard rsync on client
 > side (i.e. without restriction to the specific ssh-key).
 >   * The BackupPC-user on the server can sync using standard rsync (done
 > manually via terminal – not rsync-bpc) with rrsync set up on the
 > client (put rrsync as forced command in front of the specific server
 > key in authorized_keys).
 >   * Though, BackupPC won’t work within the same setup with rrsync forced
 > on the client. (Error log says only: "Got fatal error during xfer
 > (No files dumped for share …)"
 > 
 > Greetings
 > 
 > Am 10.02.21 um 15:45 schrieb backu...@kosowsky.org:
 > > Adam Goryachev via BackupPC-users wrote at about 23:53:38 +1100 on 
 > > Wednesday, February 10, 2021:
 > >  > 
 > >  > On 10/2/21 02:56, Felix Wolters wrote:
 > >  > > Hello!
 > >  > >
 > >  > > Let me first thank you for providing BackupPC as open source 
 > > software. I
 > >  > > appreciate it a lot and consider it to be one of the most usefull 
 > > backup
 > >  > > systems out there!
 > >  > >
 > >  > > I’d like to use it with restricted access to the client, so a
 > >  > > potentially corrupted BackupPC server wouldn’t be able to damage the
 > >  > > client machine and data. Using rsync for transfer with a Linux client,
 > >  > > rrsync (restricted rsync – as part of the rsync package) would be a
 > >  > > straigt forward solution to restrict an incoming ssh connection to 
 > > only
 > >  > > rsync and only a given folder which I will set read only – which would
 > >  > > perfectly do the trick. Unfortunately, this doesn’t seem to work with
 > >  > > BackupPC over rsync, as far as I can see. I’m positive rrsync 
 > > generally
 > >  > > works on the client as I use it successfully with plain rsync over ssh
 > >  > > on the same machine.
 > >  > >
 > >  > > I’ve seen rare information on the internet about this, and it wouldn’t
 > >  > > help me so far.
 > >  > >
 > >  > > Thank you for some help or instruction!
 > >  > 
 > >  > Hi Felix,
 > >  > 
 > >  > I'm not familiar with rrsync, but perhaps the first step would be to 
 > > try 
 > >  > it and see. If it doesn't work, then include some logs and what debug 
 > >  > steps you have taken, or other information that might help us to help 
 > > you.
 > >  > 
 > >  > Regards,
 > >  > Adam
 > >
 > > I think it depends if 'rrsync' needs to run on the client or server
 > > sides.
 > > - If it runs on the (remote) client side and is compatible with backuppc
 > >   protocols then it may work.
 > >
 > > - If it runs on the (local) server side then there is no hope for it
 > >   to work as backuppc uses its own patched version of rsync, called
 > >   rsync-bpc.
 > >   
 > >
 > >
 > > ___
 > > BackupPC-users mailing list
 > > BackupPC-users@lists.sourceforge.net
 > > List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
 > > Wik

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Les Mikesell]

On Wed, Feb 10, 2021 at 12:47 PM Felix Wolters  wrote:
>
> I may add, that working with a non-privieged user isn’t even necessary in 
> many cases, as rrsync is able to restrict access to (1.) a specific command 
> (if need be with specific options), (2.) a specific folder, and (3.) to read 
> only access – but offer full root access and allowing rsync -a to keep users, 
> groups and permissions. That makes it powerful.
>
> The problem here just seems to be that rrsync (on the client to back up) and 
> rsync-bpc are not compatible, and a patched rrsync will – hopefully! – be the 
> solution.

Isn't rrsync just a perl wrapper to start rsync but ensure it is only
accessing a permitted subdirectory?  If so it should be a matter of
tweaking the command to start it to be compatible.

-- 
   Les Mikesell
 lesmikes...@gmail.com


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Felix Wolters]

Greg,

Yupp, that’s the principle, especially refer to the paragraph
https://dev-notes.eu/2016/08/secure-rsync-between-servers/#limit-actions-for-this-ssh-connection-to-restricted-rsync

I can recommend it so far.

I may add, that working with a non-privieged user isn’t even necessary
in many cases, as rrsync is able to restrict access to (1.) a specific
command (if need be with specific options), (2.) a specific folder, and
(3.) to read only access – but offer full root access and allowing rsync
-a to keep users, groups and permissions. That makes it powerful.

The problem here just seems to be that rrsync (on the client to back up)
and rsync-bpc are not compatible, and a patched rrsync will – hopefully!
– be the solution.


Am 10.02.21 um 17:35 schrieb Greg Harris:
> Felix,
>
> I’m trying to follow along and learn a bit here.  Is this the concept
> you working towards:
>
> https://dev-notes.eu/2016/08/secure-rsync-between-servers/
>
> Thanks,
>
> Greg Harris
>
>> On Feb 10, 2021, at 11:24 AM, Felix Wolters 
>> wrote:
>>
>> Thank you, HTH, for your effort! Your setup is absolutely reasonable –
>> as long as you are on a trusted (local) network and don’t need encrypted
>> transport.
>>
>> Apart from that, the setup with rrsync would be much less complicated –
>> if it worked …
>>
>>
>> Am 10.02.21 um 17:10 schrieb G.W. Haywood via BackupPC-users:
>>> Hi there,
>>>
>>> On Wed, 10 Feb 2021, Felix Wolters wrote:
>>>
 I'd like to use it with restricted access to the client ...
>>>
>>> If I understand you correctly there's no need for complications, you
>>> can do that with plain vanilla rsyncd.  It's what I do on my machines.
>>> Forbidding ssh access further reduces the attackable surface.
>>>
>>> 1.  Set up an rsyncd daemon on the client which listens for connections
>>> from rsync on the backup server.  Configuration like this for example:
>>>
>>> 8<--
>>> ...
>>> [Config]
>>> path=/etc
>>> auth users=whatever
>>> secrets file=/etc/rsyncd.auth
>>>
>>> [Homes]
>>> path=/home
>>> auth users=whatever
>>> secrets file=/etc/rsyncd.auth
>>> ...
>>> 8<--
>>>
>>> The [words] in square brackets are what rsyncd knows as 'modules'.
>>> Any module is read-only by default, so, even if it can connect to the
>>> client's rsyncd daemon, the backup server can't write to anything in
>>> those directories.  You forbid access to anything else.  The file
>>> named in the 'secrets file' line contains just a single line with the
>>> username 'whatever' (with no quotes), a colon, and the password for
>>> that user. The user's password also appears in the Perl variable
>>> $Conf{RsyncdPasswd} in the config fragment (usually in the file called
>>> /.../BackupPC/pc/client.pl) on the backup server.  The user can be one
>>> which you create purely for backup purposes, and probably should be.
>>>
>>> 2.  Set up 'rsyncd' transfers on the backup server like this, in the
>>> file /.../BackupPC/pc/client.pl.  Obviously any other special config
>>> for the client goes in there too.
>>>
>>> 8<--
>>> $Conf{XferMethod}   = 'rsyncd';
>>> $Conf{RsyncShareName}   =
>>> ['Config','Homes','usr_local_sbin','site_perl','usr_share_perl5_email'];
>>> $Conf{RsyncdUserName}   = 'whatever';
>>> $Conf{RsyncdPasswd} = 'redacted';
>>> 8<--
>>>
>>> 3. (Optional)
>>>
>>> Instead of running the rsyncd daemon on the client 24/7 you can run it
>>> via one of the super-servers, inetd or xinetd.  Nowadays I tend to use
>>> xinetd but that's up to you.  The configurations are very different
>>> for inetd and xinetd.  Using a super-server like this lets you further
>>> restrict connections as you'll see below in the 'only_from' line:
>>>
>>> 8<--
>>> client:~ cat /etc/xinetd.d/rsyncd
>>> ...
>>> service rsync
>>> {
>>>     flags   = REUSE
>>>     socket_type = stream
>>>     port    = 873
>>>     wait    = no
>>>     user    = root
>>>     group   = root
>>>     server  = /usr/bin/rsync
>>>     server_args = --daemon
>>>     log_on_failure  += USERID
>>>     disable = no
>>>     only_from   = 127.0.0.1 192.168.1.5 192.168.1.47
>>> 192.168.1.246
>>> }
>>> 8<--
>>>
>>> If you run a super-server, don't forget that you'll need to restart it
>>> after making any change to its configuration.
>>>
>>> I've used this setup for quite a few years with no issues.
>>>
>>> HTH
>>>
>>
>>
>> ___
>> BackupPC-users mailing list
>> BackupPC-users@lists.sourceforge.net
>> List:    https://lists.sourceforge.net/lists/listin

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Greg Harris]

Felix,

I’m trying to follow along and learn a bit here.  Is this the concept you 
working towards:

https://dev-notes.eu/2016/08/secure-rsync-between-servers/

Thanks,

Greg Harris

On Feb 10, 2021, at 11:24 AM, Felix Wolters  wrote:

Thank you, HTH, for your effort! Your setup is absolutely reasonable –
as long as you are on a trusted (local) network and don’t need encrypted
transport.

Apart from that, the setup with rrsync would be much less complicated –
if it worked …


Am 10.02.21 um 17:10 schrieb G.W. Haywood via BackupPC-users:
Hi there,

On Wed, 10 Feb 2021, Felix Wolters wrote:

I'd like to use it with restricted access to the client ...

If I understand you correctly there's no need for complications, you
can do that with plain vanilla rsyncd.  It's what I do on my machines.
Forbidding ssh access further reduces the attackable surface.

1.  Set up an rsyncd daemon on the client which listens for connections
from rsync on the backup server.  Configuration like this for example:

8<--
...
[Config]
path=/etc
auth users=whatever
secrets file=/etc/rsyncd.auth

[Homes]
path=/home
auth users=whatever
secrets file=/etc/rsyncd.auth
...
8<--

The [words] in square brackets are what rsyncd knows as 'modules'.
Any module is read-only by default, so, even if it can connect to the
client's rsyncd daemon, the backup server can't write to anything in
those directories.  You forbid access to anything else.  The file
named in the 'secrets file' line contains just a single line with the
username 'whatever' (with no quotes), a colon, and the password for
that user. The user's password also appears in the Perl variable
$Conf{RsyncdPasswd} in the config fragment (usually in the file called
/.../BackupPC/pc/client.pl) on the backup server.  The user can be one
which you create purely for backup purposes, and probably should be.

2.  Set up 'rsyncd' transfers on the backup server like this, in the
file /.../BackupPC/pc/client.pl.  Obviously any other special config
for the client goes in there too.

8<--
$Conf{XferMethod}   = 'rsyncd';
$Conf{RsyncShareName}   =
['Config','Homes','usr_local_sbin','site_perl','usr_share_perl5_email'];
$Conf{RsyncdUserName}   = 'whatever';
$Conf{RsyncdPasswd} = 'redacted';
8<--

3. (Optional)

Instead of running the rsyncd daemon on the client 24/7 you can run it
via one of the super-servers, inetd or xinetd.  Nowadays I tend to use
xinetd but that's up to you.  The configurations are very different
for inetd and xinetd.  Using a super-server like this lets you further
restrict connections as you'll see below in the 'only_from' line:

8<--
client:~ cat /etc/xinetd.d/rsyncd
...
service rsync
{
flags   = REUSE
socket_type = stream
port= 873
wait= no
user= root
group   = root
server  = /usr/bin/rsync
server_args = --daemon
log_on_failure  += USERID
disable = no
only_from   = 127.0.0.1 192.168.1.5 192.168.1.47
192.168.1.246
}
8<--

If you run a super-server, don't forget that you'll need to restart it
after making any change to its configuration.

I've used this setup for quite a few years with no issues.

HTH



___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Felix Wolters]

Thank you, HTH, for your effort! Your setup is absolutely reasonable –
as long as you are on a trusted (local) network and don’t need encrypted
transport.

Apart from that, the setup with rrsync would be much less complicated –
if it worked …


Am 10.02.21 um 17:10 schrieb G.W. Haywood via BackupPC-users:
> Hi there,
>
> On Wed, 10 Feb 2021, Felix Wolters wrote:
>
>> I'd like to use it with restricted access to the client ...
>
> If I understand you correctly there's no need for complications, you
> can do that with plain vanilla rsyncd.  It's what I do on my machines.
> Forbidding ssh access further reduces the attackable surface.
>
> 1.  Set up an rsyncd daemon on the client which listens for connections
> from rsync on the backup server.  Configuration like this for example:
>
> 8<--
> ...
> [Config]
> path=/etc
> auth users=whatever
> secrets file=/etc/rsyncd.auth
>
> [Homes]
> path=/home
> auth users=whatever
> secrets file=/etc/rsyncd.auth
> ...
> 8<--
>
> The [words] in square brackets are what rsyncd knows as 'modules'.
> Any module is read-only by default, so, even if it can connect to the
> client's rsyncd daemon, the backup server can't write to anything in
> those directories.  You forbid access to anything else.  The file
> named in the 'secrets file' line contains just a single line with the
> username 'whatever' (with no quotes), a colon, and the password for
> that user. The user's password also appears in the Perl variable
> $Conf{RsyncdPasswd} in the config fragment (usually in the file called
> /.../BackupPC/pc/client.pl) on the backup server.  The user can be one
> which you create purely for backup purposes, and probably should be.
>
> 2.  Set up 'rsyncd' transfers on the backup server like this, in the
> file /.../BackupPC/pc/client.pl.  Obviously any other special config
> for the client goes in there too.
>
> 8<--
> $Conf{XferMethod}   = 'rsyncd';
> $Conf{RsyncShareName}   =
> ['Config','Homes','usr_local_sbin','site_perl','usr_share_perl5_email'];
> $Conf{RsyncdUserName}   = 'whatever';
> $Conf{RsyncdPasswd} = 'redacted';
> 8<--
>
> 3. (Optional)
>
> Instead of running the rsyncd daemon on the client 24/7 you can run it
> via one of the super-servers, inetd or xinetd.  Nowadays I tend to use
> xinetd but that's up to you.  The configurations are very different
> for inetd and xinetd.  Using a super-server like this lets you further
> restrict connections as you'll see below in the 'only_from' line:
>
> 8<--
> client:~ cat /etc/xinetd.d/rsyncd
> ...
> service rsync
> {
>     flags   = REUSE
>     socket_type = stream
>     port    = 873
>     wait    = no
>     user    = root
>     group   = root
>     server  = /usr/bin/rsync
>     server_args = --daemon
>     log_on_failure  += USERID
>     disable = no
>     only_from   = 127.0.0.1 192.168.1.5 192.168.1.47
> 192.168.1.246
> }
> 8<--
>
> If you run a super-server, don't forget that you'll need to restart it
> after making any change to its configuration.
>
> I've used this setup for quite a few years with no issues.
>
> HTH
>


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Felix Wolters]

Just to clarify: My question is about using rrsync on the remote client
to protect it (as I explained) from a potentially currupted server.
Obviously, the standard rrsync isn’t compatible with rsync-bpc. So I’m
curious about Guillermo’s adjusted version of rrsync!

What I did got so far:

  * BackupPC works without any problem with standard rsync on client
side (i.e. without restriction to the specific ssh-key).
  * The BackupPC-user on the server can sync using standard rsync (done
manually via terminal – not rsync-bpc) with rrsync set up on the
client (put rrsync as forced command in front of the specific server
key in authorized_keys).
  * Though, BackupPC won’t work within the same setup with rrsync forced
on the client. (Error log says only: "Got fatal error during xfer
(No files dumped for share …)"

Greetings

Am 10.02.21 um 15:45 schrieb backu...@kosowsky.org:
> Adam Goryachev via BackupPC-users wrote at about 23:53:38 +1100 on Wednesday, 
> February 10, 2021:
>  > 
>  > On 10/2/21 02:56, Felix Wolters wrote:
>  > > Hello!
>  > >
>  > > Let me first thank you for providing BackupPC as open source software. I
>  > > appreciate it a lot and consider it to be one of the most usefull backup
>  > > systems out there!
>  > >
>  > > I’d like to use it with restricted access to the client, so a
>  > > potentially corrupted BackupPC server wouldn’t be able to damage the
>  > > client machine and data. Using rsync for transfer with a Linux client,
>  > > rrsync (restricted rsync – as part of the rsync package) would be a
>  > > straigt forward solution to restrict an incoming ssh connection to only
>  > > rsync and only a given folder which I will set read only – which would
>  > > perfectly do the trick. Unfortunately, this doesn’t seem to work with
>  > > BackupPC over rsync, as far as I can see. I’m positive rrsync generally
>  > > works on the client as I use it successfully with plain rsync over ssh
>  > > on the same machine.
>  > >
>  > > I’ve seen rare information on the internet about this, and it wouldn’t
>  > > help me so far.
>  > >
>  > > Thank you for some help or instruction!
>  > 
>  > Hi Felix,
>  > 
>  > I'm not familiar with rrsync, but perhaps the first step would be to try 
>  > it and see. If it doesn't work, then include some logs and what debug 
>  > steps you have taken, or other information that might help us to help you.
>  > 
>  > Regards,
>  > Adam
>
> I think it depends if 'rrsync' needs to run on the client or server
> sides.
> - If it runs on the (remote) client side and is compatible with backuppc
>   protocols then it may work.
>
> - If it runs on the (local) server side then there is no hope for it
>   to work as backuppc uses its own patched version of rsync, called
>   rsync-bpc.
>   
>
>
> ___
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:https://github.com/backuppc/backuppc/wiki
> Project: https://backuppc.github.io/backuppc/
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[G.W. Haywood via BackupPC-users]

Hi there,

On Wed, 10 Feb 2021, Felix Wolters wrote:


I'd like to use it with restricted access to the client ...


If I understand you correctly there's no need for complications, you
can do that with plain vanilla rsyncd.  It's what I do on my machines.
Forbidding ssh access further reduces the attackable surface.

1.  Set up an rsyncd daemon on the client which listens for connections
from rsync on the backup server.  Configuration like this for example:

8<--
...
[Config]
path=/etc
auth users=whatever
secrets file=/etc/rsyncd.auth

[Homes]
path=/home
auth users=whatever
secrets file=/etc/rsyncd.auth
...
8<--

The [words] in square brackets are what rsyncd knows as 'modules'.
Any module is read-only by default, so, even if it can connect to the
client's rsyncd daemon, the backup server can't write to anything in
those directories.  You forbid access to anything else.  The file
named in the 'secrets file' line contains just a single line with the
username 'whatever' (with no quotes), a colon, and the password for
that user. The user's password also appears in the Perl variable
$Conf{RsyncdPasswd} in the config fragment (usually in the file called
/.../BackupPC/pc/client.pl) on the backup server.  The user can be one
which you create purely for backup purposes, and probably should be.

2.  Set up 'rsyncd' transfers on the backup server like this, in the
file /.../BackupPC/pc/client.pl.  Obviously any other special config
for the client goes in there too.

8<--
$Conf{XferMethod}   = 'rsyncd';
$Conf{RsyncShareName}   = 
['Config','Homes','usr_local_sbin','site_perl','usr_share_perl5_email'];
$Conf{RsyncdUserName}   = 'whatever';
$Conf{RsyncdPasswd} = 'redacted';
8<--

3. (Optional)

Instead of running the rsyncd daemon on the client 24/7 you can run it
via one of the super-servers, inetd or xinetd.  Nowadays I tend to use
xinetd but that's up to you.  The configurations are very different
for inetd and xinetd.  Using a super-server like this lets you further
restrict connections as you'll see below in the 'only_from' line:

8<--
client:~ cat /etc/xinetd.d/rsyncd
...
service rsync
{
flags   = REUSE
socket_type = stream
port= 873
wait= no
user= root
group   = root
server  = /usr/bin/rsync
server_args = --daemon
log_on_failure  += USERID
disable = no
only_from   = 127.0.0.1 192.168.1.5 192.168.1.47 192.168.1.246
}
8<--

If you run a super-server, don't forget that you'll need to restart it
after making any change to its configuration.

I've used this setup for quite a few years with no issues.

HTH

--

73,
Ged.


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[backuppc]

Adam Goryachev via BackupPC-users wrote at about 23:53:38 +1100 on Wednesday, 
February 10, 2021:
 > 
 > On 10/2/21 02:56, Felix Wolters wrote:
 > > Hello!
 > >
 > > Let me first thank you for providing BackupPC as open source software. I
 > > appreciate it a lot and consider it to be one of the most usefull backup
 > > systems out there!
 > >
 > > I’d like to use it with restricted access to the client, so a
 > > potentially corrupted BackupPC server wouldn’t be able to damage the
 > > client machine and data. Using rsync for transfer with a Linux client,
 > > rrsync (restricted rsync – as part of the rsync package) would be a
 > > straigt forward solution to restrict an incoming ssh connection to only
 > > rsync and only a given folder which I will set read only – which would
 > > perfectly do the trick. Unfortunately, this doesn’t seem to work with
 > > BackupPC over rsync, as far as I can see. I’m positive rrsync generally
 > > works on the client as I use it successfully with plain rsync over ssh
 > > on the same machine.
 > >
 > > I’ve seen rare information on the internet about this, and it wouldn’t
 > > help me so far.
 > >
 > > Thank you for some help or instruction!
 > 
 > Hi Felix,
 > 
 > I'm not familiar with rrsync, but perhaps the first step would be to try 
 > it and see. If it doesn't work, then include some logs and what debug 
 > steps you have taken, or other information that might help us to help you.
 > 
 > Regards,
 > Adam

I think it depends if 'rrsync' needs to run on the client or server
sides.
- If it runs on the (remote) client side and is compatible with backuppc
  protocols then it may work.

- If it runs on the (local) server side then there is no hope for it
  to work as backuppc uses its own patched version of rsync, called
  rsync-bpc.
  


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Felix Wolters]

Thank you, Guillermo in advance, this will be great!

Felix


Am 10.02.21 um 14:01 schrieb Guillermo Rozas:
> Hi,
> I use rrsync in a couple of clients. You need to slightly modify the
> rrsync script to correctly parse BackupPC rsync call, and after that
> it will work without problems. Later in the week I'll look into my
> systems and post my rrsync modified version.
> Regards,
> Guillermo
>
> On Tue, Feb 9, 2021, 13:11 Felix Wolters  > wrote:
>
> Hello!
>
> Let me first thank you for providing BackupPC as open source
> software. I
> appreciate it a lot and consider it to be one of the most usefull
> backup
> systems out there!
>
> I’d like to use it with restricted access to the client, so a
> potentially corrupted BackupPC server wouldn’t be able to damage the
> client machine and data. Using rsync for transfer with a Linux client,
> rrsync (restricted rsync – as part of the rsync package) would be a
> straigt forward solution to restrict an incoming ssh connection to
> only
> rsync and only a given folder which I will set read only – which would
> perfectly do the trick. Unfortunately, this doesn’t seem to work with
> BackupPC over rsync, as far as I can see. I’m positive rrsync
> generally
> works on the client as I use it successfully with plain rsync over ssh
> on the same machine.
>
> I’ve seen rare information on the internet about this, and it wouldn’t
> help me so far.
>
> Thank you for some help or instruction!
>
> Best
>
>
>
> ___
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> 
> List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:    https://github.com/backuppc/backuppc/wiki
> Project: https://backuppc.github.io/backuppc/
>
>
>
> ___
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:https://github.com/backuppc/backuppc/wiki
> Project: https://backuppc.github.io/backuppc/
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Guillermo Rozas]

Hi,
I use rrsync in a couple of clients. You need to slightly modify the rrsync
script to correctly parse BackupPC rsync call, and after that it will work
without problems. Later in the week I'll look into my systems and post my
rrsync modified version.
Regards,
Guillermo

On Tue, Feb 9, 2021, 13:11 Felix Wolters  wrote:

> Hello!
>
> Let me first thank you for providing BackupPC as open source software. I
> appreciate it a lot and consider it to be one of the most usefull backup
> systems out there!
>
> I’d like to use it with restricted access to the client, so a
> potentially corrupted BackupPC server wouldn’t be able to damage the
> client machine and data. Using rsync for transfer with a Linux client,
> rrsync (restricted rsync – as part of the rsync package) would be a
> straigt forward solution to restrict an incoming ssh connection to only
> rsync and only a given folder which I will set read only – which would
> perfectly do the trick. Unfortunately, this doesn’t seem to work with
> BackupPC over rsync, as far as I can see. I’m positive rrsync generally
> works on the client as I use it successfully with plain rsync over ssh
> on the same machine.
>
> I’ve seen rare information on the internet about this, and it wouldn’t
> help me so far.
>
> Thank you for some help or instruction!
>
> Best
>
>
>
> ___
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:https://github.com/backuppc/backuppc/wiki
> Project: https://backuppc.github.io/backuppc/
>
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

Re: [BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Adam Goryachev via BackupPC-users]

On 10/2/21 02:56, Felix Wolters wrote:

Hello!

Let me first thank you for providing BackupPC as open source software. I
appreciate it a lot and consider it to be one of the most usefull backup
systems out there!

I’d like to use it with restricted access to the client, so a
potentially corrupted BackupPC server wouldn’t be able to damage the
client machine and data. Using rsync for transfer with a Linux client,
rrsync (restricted rsync – as part of the rsync package) would be a
straigt forward solution to restrict an incoming ssh connection to only
rsync and only a given folder which I will set read only – which would
perfectly do the trick. Unfortunately, this doesn’t seem to work with
BackupPC over rsync, as far as I can see. I’m positive rrsync generally
works on the client as I use it successfully with plain rsync over ssh
on the same machine.

I’ve seen rare information on the internet about this, and it wouldn’t
help me so far.

Thank you for some help or instruction!


Hi Felix,

I'm not familiar with rrsync, but perhaps the first step would be to try 
it and see. If it doesn't work, then include some logs and what debug 
steps you have taken, or other information that might help us to help you.


Regards,
Adam



___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/

[BackupPC-users] Using BackupPC 4.x with rrsync on the client

[Felix Wolters]

Hello!

Let me first thank you for providing BackupPC as open source software. I
appreciate it a lot and consider it to be one of the most usefull backup
systems out there!

I’d like to use it with restricted access to the client, so a
potentially corrupted BackupPC server wouldn’t be able to damage the
client machine and data. Using rsync for transfer with a Linux client,
rrsync (restricted rsync – as part of the rsync package) would be a
straigt forward solution to restrict an incoming ssh connection to only
rsync and only a given folder which I will set read only – which would
perfectly do the trick. Unfortunately, this doesn’t seem to work with
BackupPC over rsync, as far as I can see. I’m positive rrsync generally
works on the client as I use it successfully with plain rsync over ssh
on the same machine.

I’ve seen rare information on the internet about this, and it wouldn’t
help me so far.

Thank you for some help or instruction!

Best



___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/