Learn Rsync - Remote Mode: SSH & Rsync Daemon

#Introduction

Episode 3 stayed within local mode. Now it's time to cross the network — because rsync's real power shows when you can sync data between servers. Episode 4 covers two remote paths: SSH and the rsync daemon.

The choice isn't about "which is better", but "which fits your needs": SSH for secure private backups, the daemon for sharing modules with many clients. You'll master both in this episode.

#Remote via SSH

The most common and secure way is over SSH. Rsync uses SSH as both transport and authentication:

Pull from a remote host

rsync -avh user@host:/var/www/ ./www-backup/

Push to a remote host

rsync -avh ./www-backup/ user@host:/var/www/

The direction determines the role: pull brings data from remote to local, push sends it from local to remote. Both are equally valid; choose based on which side you want to control from (and where reading logs/exit codes is easiest for you).

#Custom Port with -e

When SSH runs on a non-default port, use -e to define the shell command:

SSH on port 2222

rsync -avh -e "ssh -p 2222" user@host:/data/ ./data/

-e "ssh -p 2222" tells rsync which transport command to use. This is also the doorway to other SSH options — like a specific key file or a proxy jump — which we'll harden in episode 14.

Note

Since rsync 3.x, rsync:// and :: require --protocol=29 if you want to force the old SSH mode; but the modern practice is: for SSH, just use the user@host:/path syntax like above. The host::module and rsync://host/module syntaxes are specifically for the daemon.

#The Rsync Daemon: Syntax and Modules

Daemon mode runs on port 873. Its syntax is rsync://host/module/ or host::module. The server exposes one or more modules — a logical name mapped to a physical path:

Pull from a daemon module

rsync -avh rsync://backup-host/backup/ ./restored/

Note the two colons vs rsync:// — they're equivalent, so pick whichever is easier to read in your scripts. For modules that need authentication, add the daemon user:

Daemon with authentication

rsync -avh rsyncuser@backup-host::backup/ ./restored/

#Configuring /etc/rsyncd.conf

On the server side, modules are defined in /etc/rsyncd.conf. Here's a complete example:

/etc/rsyncd.conf

uid = rsyncuser
gid = rsyncuser
use chroot = yes
max connections = 5
pid file = /var/run/rsyncd.pid
log file = /var/log/rsync.log
 
[backup]
path = /srv/backup
comment = Main server backup
read only = yes
auth users = rsyncuser
secrets file = /etc/rsyncd.secrets

The global section (no title) applies to all modules; the [backup] section is the module named backup. read only = yes means clients can only pull — the safest configuration for backups. use chroot = yes locks the module inside its path, preventing clients from accessing other directories.

#Secrets File Authentication

For protected modules, rsyncd uses a secrets file — a file containing user:password pairs:

Create the secrets file

echo "rsyncuser:S3curePass" | sudo tee /etc/rsyncd.secrets
sudo chmod 600 /etc/rsyncd.secrets
sudo chown rsyncuser /etc/rsyncd.secrets

chmod 600 is mandatory — rsyncd will refuse a secrets file readable by other processes. On the client side, authentication can be passed automatically via --password-file:

Non-interactive authentication on the client

echo "S3curePass" > ~/.rsync.pass
chmod 600 ~/.rsync.pass
rsync -avh --password-file=~/.rsync.pass rsyncuser@backup-host::backup/ ./restored/

With this, cron can run pulls without password input. Note: the client password file must also be chmod 600.

Important

Rsync daemon authentication is not a substitute for encryption: credentials and data still flow in plaintext on port 873. For sensitive data, use SSH instead, or wrap the daemon in an SSH tunnel (episode 14). Never expose port 873 to the internet without a firewall.

#SSH vs Daemon: When to Use Which

Scenario	Choice
Private server backup, migration	SSH — encrypted, key authentication
Public mirror to many clients	Daemon — no shell account per user
Sharing directories between internal servers	SSH — simpler, no daemon
Periodic non-interactive pulls for many clients	Daemon with `--password-file`

Tip

80/20 rule: in modern production environments, 90% of cases are fine with SSH alone. The daemon is most useful for public mirrors and when you want to confine clients to a single directory without giving shell access. Start with SSH, and move to the daemon only if there's a real need.

#Closing

In this episode you've mastered remote mode through two paths.

Key takeaways:

SSH: rsync -avh user@host:/path/ ./ for pull/push; custom port via -e "ssh -p 2222".
Daemon: rsync://host/module/ on port 873; modules are defined in /etc/rsyncd.conf.
Secrets files must be chmod 600, both on the server and the client (--password-file).
Port 873 is not encrypted; for sensitive data use SSH or an SSH tunnel.
SSH for the majority of cases; the daemon for public mirrors and file-sharing modules.

In episode 5 we dissect the essential flags: -a (archive), -v, -h, -z (compression), -P (--partial + --progress), --delete, and -n (dry-run) — the foundation of almost every rsync command you'll write. See you in episode 5!