Force Rsync Daemon Over SSH

Question

Thanks to the sharp eye of @roaima it has come to my attention that my remote server backup script below, does NOT actually use the SSH encryption as I would like it to.

I based my rsync command on the example found here:
https://www.man7.org/linux/man-pages/man1/rsync.1.html

rsync -av -e "ssh -l ssh-user" rsync-user@host::module /dest

However, what is actually happening when my current backup script executes is:

1.) it connects to ssh as the designated user, then
2.) my login notification script confirms the ssh user's login with an email (repeats on disconnect/re-connects),
3.) PROBLEM: The rsync daemon connects and does its business -outside- the ssh shell, meaning I don't actually get the ssh shell encryption that I want.

I verified this by executing the backup script and then on the remote server executing the who command, which confirms that the ssh-backup-user is -not- connected to the server while the rsync daemon is executing.

My current backup script (has to executed as non-root user)

#!/bin/bash
while [ 1 ]
do
     rsync -avxP --delete --append --checksum --timeout=180 --bwlimit=150 --rsync-path="sudo rsync" --log-file=/var/log/rsync.log --password-file=/etc/rsyncd.passwd -e "ssh -l backup-user" 111.22.333.444::data /media/user/WebMade/Server-Backups/Prod/today/
    if [ "$?" = "0" ] ; then
        echo "rsync completed normally"
        exit
    else
        echo "Rsync failure. Backing off and retrying..."
        sleep 10
    fi
done
#EOF

Might someone be able to clarify whats happening, either I am misunderstanding the man page (most likely :-/ ) or the provided example is wrong.

Thanks

Answer 1

Everything is just fine, there's no problem here.

The other answers here are partially wrong and partially missing the point. What you have done is the correct documented way to spawn and communicate with the rsync daemon through an SSH connection. For those unfamiliar with this mode, I recommend checking out the section of the rsync manual called "USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION".

Setting --rsh or -e to ssh in combination with the double-colon :: syntax enables this mode. Rsync will then connect to the remote machine using ssh, spawn a daemon there (under the SSH session) and communicate with it through the SSH tunnel. This is a very useful mode because it lets you use daemon-only features together with SSH authentication and encryption.

who is not telling you what you think it does. who (just as w and other alternatives) only lists interactive sessions, the ssh session used to launch the rsync daemon is not interactive (doesn't even use a shell at all), so it won't appear here. If you don't just trust rsync to do what it says in the manual, you can use ps -efH to see the ssh session and the rsync daemon running on the remote machine, ss -t to see there's no TCP connection between the machines apart from the SSH on port 22, or strace on the rsync process to see the rsync process communicating with the ssh process.

Answer 2

The presence of a double colon (::) in a source of target path indicates use of the rsyncd service. A single colon (:) indicates a login (typically) over ssh.

Once you do that, the remote path must then either start with / or it's relative to the home directory the account would log in to.

For example

[email protected]:docroot

Remove --checksum and let rsync decide when to use one. (The only time it automatically skips a checksum is when the file size and modification time match on both sides.)

Stop using any variation of --append as otherwise you will end up with data corruption in your backups sooner or later. You will almost certainly have wanted --partial here, and that's already included in -P.

For a ssh login backup-user on the remote system 203.0.113.1 that has (say) two directories logs and website, you would then use a command line like this to backup:

 rsync -aivP --delete [email protected]:website/ /my/local/copy

I now understand from a comment that you need to copy files from an rsyncd service but you want to transfer them across an ssh connection that provides a secure (encrypted) transport. Conveniently the man page for rsync actually has this an an example: you set the environment variable RSYNC_CONNECT_PROG to define the ssh tunnel and then connect to the rsyncd service within the command itself:

RSYNC_CONNECT_PROG='ssh [email protected] nc %H 873' rsync -aivP --delete localhost::data/ /my/local/copy

Be careful, though. Neither solution gives you no long-term protection against a corruption such as a web page hijacked for a trojan. You replace your backup with a full copy of live each time, so a mistake on live will propagate to your backup as soon as you run your backup script. Consider GFS or some other multilevel backup schedule (three different backups, one each for Sunday, Tuesday, Thursday would be a start). A tool such as rsnapshot can implement this efficiently as a layer above rsync.