I want a backup host to be able to pull backups from a remote host.

The backup host uses ssh key authentication to authenticate as a restricted user on the remote host, this user is restricted to the rsync command using the authorized_key file.

/etc/sudoers allows the user to execute rsync as superuser.

The backup host should logically only be able to read files / copy files from the remote host, not write files / copy files to the remote host, as it could easily compromise the remote host by overwriting /etc/passwd or just tamper with the files if it were compromised itself.

How can I achieve this? I already read about rrsync, but didn't see an option which allowed this.

6 Answers 6


The -ro flag of rrsync ensures that rsync is called with the --sender option, which should, according to the rrsync documentation, ensure that files can only be read - however, I could not find a authoritive source (aka rsync documentation) which confirms that. In my tests, it was sufficient to prevent writes to the server.


Have a look at authprogs - I was using it for a quite similar scenario (backuppc via ssh)


This is close to necromancing, but still I found this question first and feel this is incomplete, because it relies on external programs.

So in pull mode, on the receiver's side, the read-only mode presupposes trust though. As a backup method above commands might work well as long as only the properly configured client requests the data. If you want to restrict what rsync over ssh can do one remote setting ro client side may not be enough.

If you have access to the server the data is being pulled from over SSH there is some simple extra configuration to be done to restrict what the logged in user can do. SSH, used with a public and a private key, offers this additional way of ensuring the client can call a specific command only.

This is how its done. On the server, where the data is being pulled from, there is a ~/.ssh/known_hosts file in user's home directory. The file holds one line per host that it knows the pubkey of, like this

ssh-dss AAAAB3....o9M9qz4xqGCqGXoJw= user@host

Prefix that with the command you wanat to allow

command="/bin/myscript.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAAB3....o9M9qz4xqGCqGXoJw= user@host

to have it such that user@host can only execute /bin/myscript.sh on remote.

A related question with good answers is over at the SO site.


[Disclosure: I wrote sshdo which is described below]

As mentioned above, rrsync can be used to control what rsync can do over ssh but, like most uses of ssh forced commands, it's limited to a single rsync command per authorized key.

Another way to control what rsync can do over ssh is to use a generic command whitelisting control for ssh.

There's a program called sshdo for doing this. It controls which commands may be executed via incoming ssh connections. It's available for download at:

http://raf.org/sshdo/ (read manual pages here)

It has a training mode to allow all commands that are attempted, and a --learn option to produce the configuration needed to allow learned commands permanently. Then training mode can be turned off and any other commands will not be executed.

It also has an --unlearn option to stop allowing commands that are no longer in use so as to maintain strict least privilege as requirements change over time.

It is very fussy about what it allows. It won't allow a command with any arguments. Only complete shell commands can be allowed.

But it does support simple patterns to represent similar commands that vary only in the digits that appear on the command line (e.g. sequence numbers or date/time stamps).

It's like a firewall or whitelisting control for ssh commands.


As mentioned above by Zulakis, the undocumented --server and --sender options seem to start rsync on the sender server in read-only mode.

Therefore I configured on the server a sudoers file:

backuppc ALL=NOPASSWD: /usr/bin/rsync --server --sender *

Using this commando I was not able to upload or overwrites file on the server. Unfortunately it is NOT safe, because the client can still easily delete files from the server by deleting them after download, e.g.:

rsync -v -e ssh --remove-source-files --rsync-path="sudo /usr/bin/rsync --server --sender" server.to.backup:/etc/network/interfaces .

downloads the file and deletes it afterwards.

Hence, an attacker which hijacked the backup server, can trigger a final backup and deletes all backuped file from the server.

Hence, I was not able to find a read-only mode for backuppc.

See https://unix.stackexchange.com/a/539173 for a probably better method using "capabilities".


I know this question is very old but here are few suggestion that may prove helpful.

The easy way, there are docker openssh-server images or roll your own. Map ssh to a non-standard port and setup the volumes you wish to expose as read only. There should be no way for rsync to write to the mapped volumes.

The not so easy way would be to setup chroot'ed user. The trick is to give the user access to a read only bind mount or a read only wrapfs mount.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.