We have the following authorized_key file that we sync across all our hosts to use with our rsnapshot cron job:

command="rsync --server --sender -logDtprRe.iLsfxC --numeric-ids -- . \"${SSH_ORIGINAL_COMMAND#* . }\"" \
ssh-rsa AAAAB3NzaC1yc2EA...ER9+vQ== [email protected]

Last argument may differ from host to host (meaning you could get access to any file you like).

  • Is there any safer way use rsnapshot in a cronjob?
  • Is using double quotes reasonably save against injecting arguments?
  • Is there a possibility of reading relevant data via /proc or /sys?
  • Can the rsync server modify any files on the host?
  • Is getting password & private keys from insides the files (config files, /etc/password) being rsynced the only reasonable attack (guess we would need a reverse encfs mount on the host to mitigate this risk)?

Note: the arguments (incl. --server --sender) are copied from what rsync within rsnapshot calls over SSH, that is also why I am pretty unsure if someone e.g. could e.g. delete/overwrite arbitrary files over the rsync protocol (e.g. /root/ssh/authorized_keys) making the whole effort pointless.

  • I'm not sure what you mean by "Is getting (hashed) password/private keys insides of files the only reasonable attack (guess we would need a reverse encfs mount in a script to mitigate any risks here)?", can you clarify?
    – David
    Commented Jan 17, 2018 at 2:41
  • 1
    I would use full rsync path. Also note in rsync manual: "The options --server and --sender are used internally by rsync, and should never be typed by a user under normal circumstances. [..] For instance, the support directory of the rsync distribution has an example script named rrsync (for restricted rsync) that can be used with a restricted ssh login.". Can't you do without the SSH_ORIGINAL_COMMAND? I do not know what would happen if it has "; echo /etc/passwd" in it. Commented Jan 17, 2018 at 15:13
  • "133.713.370" is a funny IP address... next time for obfuscation please use the IP blocks defined in RFC5737 Commented Jan 17, 2018 at 15:13
  • The rrsync is exactly what I think I looked for! samba.org/ftp/unpacked/rsync/support/rrsync . I think they are exactly working around the insecure stuff here. The actually use SSH_ORIGINAL_COMMAND originally. I think I need it so that we can sync different directories as requested by the client.
    – till
    Commented Jan 18, 2018 at 18:00

1 Answer 1


[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 (or single directory anyway). What if you want to rsync multiple areas of the file system? What if you want to execute some non-rsync commands as well? How many authorized keys would you need to create and install?

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).

You must log in to answer this question.

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