4

I'm trying to create an automated back up of various folders on my server, some of these require root access to read them. I realise that I can rsync as per this answer, namely I can (with success) do

rsync ... --rsync-path="sudo rsync" ...

However, this solution means that I have to add a public ssh-key to a user that has sudo rights (or at least sudo rights to use rsync). Since rsync is such a powerful tool, I would like to add more protection by either

  1. adding a passphrase to the private ssh-key, or
  2. limiting what actions that user can do via rsync.

The former is not really possible with an automated back up. And it seems that "rrsync" is geared up to do the latter, see here.

However, I'm having problems with accessing folders that require root access using rrsync. I followed the above rrsync tutorial, and set up rrsync on the remote server in ~/.ssh/authorized_keys by prepending the key with

command="/path/to/rrsync -ro /path/to/backups/"

and then attempting to locally run

rsync ... --rsync-path="sudo rsync" ...

then rrsync throws an error. Namely:

/path/to/rrsync: SSH_ORIGINAL_COMMAND='sudo /usr/bin/rsync --server --sender ...' is not rsync

Therefore, my understanding is that rrsync does not allow one to use "sudo rsync" with it. Is this a shortcoming of rrsync or intentional? Or is there another way that I can achieve what I'm trying to do?

3 Answers 3

2

To use rrsync with sudo you need to configure sudo to retain the SSH_ORIGINAL_COMMAND environment variable.

Configure ssh for your remote server backup user to always run sudo rrsync by editing on the remote server ~/.ssh/authorized_keys to contain:

command="/usr/bin/sudo /usr/bin/rrsync -ro /path/to/backups/" ssh-rsa AAAA...

sudo on the remote server needs to retain the SSH_ORIGINAL_COMMAND environment variable which is set by sshd when using the command configuration above and is required by rrsync. To do this on the remote server run visudo /etc/sudoers.d/rrsync and enter the following:

Defaults!/usr/bin/rrsync env_keep += "SSH_ORIGINAL_COMMAND"
backup_user ALL = (root) NOPASSWD: /usr/bin/rrsync

Replace backup_user with the username you ssh into the remote server with.

You can now rsync the remote directory to the local server by running this on the local server:

rsync -axv backup_user@remote-server:/path/to/backups/ local-backups/
0

Have you thought of trying to use a NFS with rights given to a certain user? I guess more information about the security of the destination and the current server would be helpful in finding another solution... or maybe understanding your current rsync solution a little better. I am confused on why you think the ssh key would be password protected. If you are root and root is running rsync... then you can access any file... including any ssh key you have.

1
  • 1
    Thanks for your answer. Apologies, on reread I've realised that "I don't want to password protect the ssh key" is not clear enough. I'll edit to clarify. I'm afraid I don't know what a NFS solution would look like - could you expand on that a little bit?
    – myquest
    Nov 10, 2020 at 9:26
0

One way to limit rsync's rights is to run it as a daemon on the server. Typically, you would have a configuration file /etc/rsyncd.conf which specifies which directories can be copied, or written into, and rsync would listen permanently for connections on a given port for a client to send requests (using the :: syntax instead of : in user@host:/dir). Unfortunately, the data is not encrypted, and authentication is by a simple plaintext password, so this is only viable on a trusted network.

However, you can also have rsync run in this mode inside an ssh connection. This restores the network security. You still need the user to run sudo on rsync, but with a fixed set of arguments. The sudoers entry would be:

user clienthost = NOPASSWD: /usr/bin/rsync --config=/etc/myconfig --server --daemon .

Note the "." at the end.. The client would run:

rsync -a --rsh=ssh --rsync-path='sudo rsync --config=/etc/myconfig' \
 remote::dir1/a/b /local/a/b

Note that rsync adds the extra options. Also, the --rsh option is needed else the :: syntax will expect to be connecting to an already running daemon. The /etc/myconfig file (write-only to root) would be:

log file = /var/log/mylog
[dir1]
path=/x/y/z
use chroot = true
read only = true
uid = 0

The client's dir1/a/b is mapped to /x/y/z/a/b on the remote.

If desired the sudo rsync --config=/etc/myconfig can be fixed in the command= part of the user's ~/.ssh/authorized_keys file, but will need to have the --server --daemon . part added, as ssh will ignore the client's command in this case.

Be sure to read man rsyncd.conf and the rsync man page description of the daemon mode before embarking on this solution.

1
  • Many thanks for the detailed answer. I'll have a look into this.
    – myquest
    Nov 12, 2020 at 16:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .