I had a look at the restricted rsync script, rrsync, which is mentioned in
man rsync. Basically the client
rsync command seems to pass all of its options through, to the remote
rsync command that it runs over SSH.
rrsync is a 200+ line perl script that people use, to restrict which paths and options the server allows. My initial reaction to this is "arrgh". It does not help that the
rsync documentation is deliberately vague about how the
--server option is actually used.
I also found a 2016 bug report showing a massive security hole in
rrsync. It is still not fixed.
I would prefer to define legal targets and options using
rsyncd.conf. At the same time, I want to use SSH encryption and authentication to protect my connection to the rsync server.
It looks like I can do this using an
~/.authorized_keys with a dedicated SSH key, and options to restrict it like
command="/usr/bin/rsync --server --daemon --config=./rsyncd.conf .",restrict. Then I can run my
rsync client command using the daemon syntax:
rsync -e "ssh" "$SOURCE_PATH" "$SSH_HOST"::"$RSYNC_MODULE"/"$DEST_PATH".
(If you don't use SSH keys, you could do the same thing using a dedicated user,
/etc/sshd_config, Match, and ForceCommand. There is currently no equivalent of the blanket
restrict though, you have to disable all the permissions individually).
Does this work reliably?
I tested a few different options. My
rsync command seems to consistently launch
rsync --server --daemon ., even if I add options to the client command like
Question: Can I rely on the above? Or contrawise, is there some case where the client might need to launch the daemon server using a different set of options?
Is the third argument -
. - ever set to anything else? What does it do??