vgartner's Blog

I like to backup some logging, mail, and configuration information sometimes on hosts across the network and Internet, and here is a way I have found to do it. You’ll need these packages installed:

• rsync
• openssh
• cron (or vixie-cron)

Please note these instructions may be specific to Red Hat Linux versions 7.3, 9, and Fedora Core 3, but I hope they won’t be too hard to adapt to almost any *NIX type OS. The man pages for ’ssh’ and ‘rsync’ should be helpful to you if you need to change some things (use the “man ssh” and “man rsync” commands).

First, I’ll define some variables. In my explanation, I will be synchronizing files (copying only new or changed files) one way, and I will be starting this process from the host I want to copy things to. In other words, I will be syncing files from /remote/dir/ on remotehost, as remoteuser, to /this/dir/ on thishost, as thisuser.

I want to make sure that ‘rsync’ over ’ssh’ works at all before I begin to automate the process, so I test it first as thisuser:

and type in remoteuser@remotehost’s password when prompted.
I do need to make sure that remoteuser has read permissions to /remote/dir/ on remotehost, and that thisuser has write permissions to /this/dir/ on thishost. Also, ‘rsync’ and ’ssh’ should be in thisuser’s path (use “which ssh” and “which rsync"), ‘rsync’ should be in remoteuser’s path, and ’sshd’ should be running on remotehost.

serves no purpose until we put the public portion into the ‘authorized_keys’ file [2] on remotehost, specifically the one for remoteuser:

I use scp to get the file over to remotehost:

and then I can prepare things on remotehost.

I ’ssh’ over to remotehost:

I need to make sure I have the directory and files I need to authorize connections with this key [3]:

Now the key can be used to make connections to this host, but these connections can be from anywhere (that the ssh daemon on remotehost allows connections from) and they can do anything (that remoteuser can do), and I don’t want that. I edit the ‘authorized_keys’ file (with vi) and modify the line with ‘thishost-rsync-key.pub’ information on it. I will only be adding a few things in front of what is already there, changing the line from this:

to this [4]:

where “10.1.1.1″ is the IP (version 4 [5]) address of thishost, and “/home/remoteuser/cron/validate-rsync” (which is just one of a few options [6], including customization [7] to enhance security) is a script that looks something like this:

If thishost has a variable address, or shares its address (via NAT or
something similar) with hosts you do not trust, omit the ‘from="10.1.1.1″,’
part of the line (including the comma), but leave the ‘command’ portion.
This way, only the ‘rsync’ will be possible from connections using this
key. Make certain that the ‘validate-rsync’ script is executable
by remoteuser on remotehost and test it.

ALSO NOTE:

Another security detail to consider is the SSH daemon configuration on
remotehost. This example focuses on a user (remoteuser)
who is not root. I recommend not using root as the remote
user because root has access to every file on remotehost.
That capability alone is very dangerous, and the penalties for a mistake
or misconfiguration can be far steeper than those for a ‘normal’ user.
If you do not use root as your remote user (ever), and you make
security decisions for remotehost, I recommend either:

or:

be included in the ‘/etc/ssh/sshd_config’ file on remotehost.
These are global settings, not just related to this connection, so be
sure you do not need the capability these configuration options prohibit.
[8].

Now that I have the key with no password in place and configured, I need
to test it out before putting it in a cron job (which has its own small
set of baggage). I exit from the ssh session to remotehost and try:

If this doesn’t work, I will take off the “command” restriction on the key
and try again. If it asks for a password, I will check permissions on the
private key file (on thishost, should be 600), on ‘authorized_keys’
and (on remotehost, should be 600), on the ‘~/.ssh/’ directory
(on both hosts, should be 700), and on the home directory (’~/’) itself
(on both hosts, should not be writeable by anyone but the user).
If some cryptic ‘rsync’ protocol error occurs mentioning the
‘validate-rsync’ script, I will make sure the permissions on
‘validate-rsync’ (on remotehost, may be 755 if every

remotehost user is trusted) allow remoteuser
to read and execute it.

The last step is the cron script. I use something like this:

When I get the script running successfully, I use ‘crontab -e’ to
insert a line for this new cron job:

for a daily 5 AM sync, or:

for a weekly (5 AM on Fridays). Monthly and yearly ones are rarer for me, so look at “man crontab” or here for advice on those.

Links:

• Rsync
• Rsync Tutorial
• OpenSSH
• SSH, The Definitive Guide
• OpenSSH Key Management, Part 1
  
  Part 2
  
  Part 3

• Securing SSH

• Rsync + Stunnel 4.x (for another way to secure rsync)
• Using Rsnapshot and SSH
• Versione in italiano by Paolo Marsi

www.jdmz.net

troy.jdmz.net