Ssh – Allow the restricted rsync (rrsync) script for arbitrary directories with authorized_keys

backuprsyncssh

Automating Backups

I would like to implement a backup solution with copies data from various directories from a Web server (WebServer) to a local backup server (BackupServer). The backup should run unattended and therefore I would like to use a key based authentication with a passwordless private key.

Privileged Rsync

The directories I want to backup are only readable by a privileged user. I would like to use rsync to copy the files. I created a dedicated backup-user and allow the user to execute rsync with sudo without being prompted for a password with the visudo rule:

backup-user ALL = NOPASSWD: /usr/bin/rsync

Security Considerations

I would like to improve security by restricting the commands the backup user can execute by adding a list of commands to the authorized_keys file of the WebServer. I installed rrsync as mentioned in this post.

command="/usr/bin/rrsync",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAA134143NzaC1yc...

Rrsync expects a subdirectory

In contrast to the normal rsync, the rrsync expects a subdirectory to be provided in the authorized key file, as described in this blog post

command="/usr/share/rsync/rrsync  /var/backup/client1/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa

This restriction works but it only allows me to backup one specific directory namely the /var/backup/client1/

I would like to provide the directories I want to backup from the BackupServer in the rsync command. Is there a possibility to use rrsync exactly like rsync, e.g.:

rsync -avze ssh --rsync-path='sudo rrsync' backupuser@111.222.33.44:/media/data  /backups/Server/

Additional Clarification

I am aware that the command="…" part in authorized_hosts does limit the executable commands for this user to exactly the ones provided, but with the normal rsync, I can do something like this to provide the path I want to backup as a parameter:

command="/usr/bin/rsync --server --sender -vlogDtpre.is . ${SSH_ORIGINAL_COMMAND//* \//\/}"

This does not work with rrsync.

Accepted Solution

Although technically not the definitice answer to the question, I think the solution posted by Gilles is a very nice approach. I created a root folder for all the views of the actual directory that I want to backup. For this reason I can safely restrict the authentication to rrsync only.

One time todo

    sudo mkdir /mnt/Backups-Rsync-Readonly
    sudo chown -R rsync-backup /mnt/Backups-Rsync-Readonly
    sudo mkdir /mnt/Backups-Rsync-Readonly/VAR-WWW
    sudo mkdir /mnt/Backups-Rsync-Readonly/MySQL-Backups
    sudo setfacl -m u:rsync-backup:rx /mnt/Backups-Rsync-Readonly/
    sudo setfacl -m u:rsync-backup:rx /mnt/Backups-Rsync-Readonly/MySQL-Backups
    sudo setfacl -m u:rsync-backup:rx /mnt/Backups-Rsync-Readonly/VAR-WWW

Create views (gone after reboot)

    sudo bindfs -o perms=0000:u=rD,force-user=rsync-backup /var/www /mnt/Backups-Rsync-Readonly/VAR-WWW
    sudo bindfs -o perms=0000:u=rD,force-user=rsync-backup /MySQL-Dumps /mnt/Backups-Rsync-Readonly/MySQL-Backups

Fstab version

    /home/stefan/Scans    /mnt/Backups-Rsync-Readonly/VAR-WWW fuse.bindfs perms=0000:u=rD,force-user=rsync-backup 0   0

Authorized_keys

command="/usr/bin/rrsync -ro /mnt/Backups-Rsync-Readonly",from="192.168.0.10",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB

Best Answer

One possibility would be to create a read-only view of the directories you want that dedicated user to be able to back up, with bindfs. Do not use sudo at all; make rrsync the only command that's allowed to this user. One-time setup:

mkdir /somewhere/backup-views /somewhere/backup-views/dir1 /somewhere/backup-views/dir2
chmod 700 /somewhere/backup-views
setfacl -m u:rx:backup-user /somewhere/backup-views

Setup after each boot:

bindfs -o perms=a+r-w /actual/dir1 /somewhere/backup-views/dir1
bindfs -o perms=a+r-w /actual/dir2 /somewhere/backup-views/dir2

Or corresponding lines in /etc/fstab:

/actual/dir1 /somewhere/backup-views/dir1 bindfs perms=a+r-w
/actual/dir2 /somewhere/backup-views/dir2 bindfs perms=a+r-w

Then set up the backup user to run rsync on /somewhere/backup-views.

Related Solutions

Rsync Backup – Preserve Date Modified on Directories with Rsync

The last modification time of directories is preserved by -a, but you can only see this when rsync finishes. It does not try to set the time on directories that are constantly being updated with new files.

You can test this yourself. Create a directory and set the date on it to yesterday, then copy it with rsync:

$ mkdir d1 d2
$ ls -ld d1
drwxr-xr-x 2  40 Nov  4 14:41 d1
$ touch -d 'yesterday' d1
$ ls -ld d1
drwxr-xr-x 2  40 Nov  3 14:41 d1
$ rsync -i -avR d1 d2
$ ls -ld d1 d2/d1/
drwxr-xr-x 2  40 Nov  3 14:41 d1
drwxr-xr-x 2  40 Nov  3 14:41 d2/d1/

The d2/d1 dir has yesterday's date. We can override it and see if rsync fixes things:

$ touch d2/d1
$ ls -ld d1 d2/d1/
drwxr-xr-x 2  40 Nov  3 14:41 d1
drwxr-xr-x 2  40 Nov  4 14:42 d2/d1/
$ rsync -i -avR d1 d2
.d..t...... d1/
$ ls -ld d1 d2/d1/
drwxr-xr-x 2  40 Nov  3 14:41 d1
drwxr-xr-x 2  40 Nov  3 14:41 d2/d1/

rsync -i shows the timestamp is wrong on d2/d1 and fixes it.

Rsync: compare directories with symlinks

Using normal commands with symlinks is very tricky. find command handles them pretty well. So the key is to use find, and I'd suggest using a fast CRC or cryptographic hash function depending on your needs.

So something like this should work (you can make supplements as needed)

find -L www -type f -exec cksum {} \; | cut -d ' ' -f1-2 | md5sum

If you want cryptographic backing for your checksums,

find -L www -type f -exec sha256sum {} \; | cut -d ' ' -f1 | sha256sum

The 'type' identifier is required because sha256 only works on files and errors out for directories, and the cut is only used to pass the checksum/hash to the final function and avoid false positives when in reality only the path names are different.

Note: This will fail in case the symlink is not relative and if the two systems don't have the exact same path which can happen if a symlink points outside the directory you are running find on.