My first setup of a remote backup system using rsync looked somthing like this:

backupserver# rsync -uav root@remote:/ /mnt/backup/remote/

This was automated using cron and ssh keys. However with this setup the backupserver is granted more acces than needed. In short if the backup server account is compromised the remote server will too.

To improve this setup I had a few goals:

• All system files must be backed up, including protected files only accessible by root.
• The backup server account will not be able to do any damage to files on the remote server.
• The backup will be initiated by the backup server

The last goal has to do with my backup server being behind NAT that I’m not in control of.

A very good article describing the priciple solution is at YC’s playgroundLearningLinux : Fully restricting rsync options server-side . Most of my final solution will include the advice found there but there will also include other options found elsewhere.

Rsync remote

First a quick introduction on rsync via ssh.

When rsync is used one instance is started locally and another is invoked on the remote server via ssh. For eacmple when the command is executed on the local server:

local# rsync -vxrlp remote:/ /mnt/backup/remote/

The following will be initiated on the remote by the local via ssh:

remote# rsync --server --sender -vlprxe.iLs . /

Normally the initiating server can choose any program to invoke on the remote machine and any parameters. This is what we want to limit so that only rsync is allowed and only using parameters we deem safe to use.

Restricting ssh access to rsync only

The main issue is how to grant a user on the backup server root privilege file access on the remote server. I have found a few different ways of solving this without any specific order. Common for all solutions is that they specify on the remote server side what program to run(rsync) and using specific parameters. This is combined with giving this session root privileges.

The SSH daemon system configuration solution

In the sshd configuration file you can match on user and specify specific commands. Here the ForceCommand allow us to limit a specific user to only communicate with rsync using our parameters.

/etc/ssh/sshd_config:
Match User backup
ForceCommand sudo /root/rsync-backup

Here we force a specific command to be used by the backup user on the remote server. The rsync-backup is a simple bash script where we specify what parameters we want to run rsync with.

/root/rsync-backup:
#!/bin/bash
rsync --server --sender -vlprxe.iLs . /

This user will not have root privileges and therefore we use sudo to grant that.

$ visudo, and add the line
backup  ALL=(ALL)       NOPASSWD: /root/rsync-backup

One limitation to this solution is at the server configuration. If I switch to another ssh server, such as dropbear, It would not follow the ForceCommand instructions resulting in arbitrary access although only as user backup.

The Authorized keys solution

A somewhat more local configured solution is using the command parameter in authorized_keys. It allow us to specify which command to run when a specific key is used for ssh access. This allows us to grant the backup server user to direct root access on the remote server with specific limitations.

/root/.ssh/authorized_keys
command="rsync --server --sender -vlprxe.iLs . /" ssh-rsa AAA...AF2Q== backup@backup-server

Here we have granted the backup user root access but with limitation to one command. SSH servers not honoring the authorized_keys file will not grant any access instead. Thus this did not seem to work in dropbear which requested password.

User shell limitation

A third solution that works in DropBear as well as for OpenSSH is to specify the rsync-backup script described above in the passwd file

/etc/passwd, change from to:
backup:x:1018:1038::/home/backup:/bin/bash
backup:x:1018:1038::/home/backup:/root/rsync-backup

The last parameter in this colon separated list specify the shell that user may call.

Conclusion

The authorized_keys solution seem to be the simplest solution. The other solutions might be an option when mixing with other ssh servers although that is not recommended from a security perspective.