To the skilled Linux user, rsync and the OpenSSH suite aren't strangers. In fact, they're frequently used and praised by a lot of people for their convenience and versatility. Together they form an excellent remote backup solution.

Rsync supports operations over SSH out of the box. So far there's no problem. To automate those backups, however, you'll need to run a job scheduler (like Dillon's cron daemon). This doesn't pose any problems either - running it unattended does though...

However, this is also where the fun begins ;-). I already pointed out in a previous article how to set up ssh-agent correctly, so I'll skip that. You can set up ssh-agent all neatly (I was very proud of that personally), but as the Gentoo guys know (and as I found out the hard way), cron runs its own environment, which does not inherit everything from your typical user environment. So, although cron will run the script with the UID of the user defined (by putting it in the user's crontab), it will lack some environment variables - notably the SSH_AUTH_SOCK variable, which is essential for automated SSH connections. Without you'll be unable to perform backups without user intervention - and that's what we're looking for.

Gentoo may not be all that it was anymore, but it's clear from the previous link its documentation is still top-notch, and they still got the skills too. In fact it was a gentoo user that wrote a script to remedy the cron problem, called keychain, a wrapper script now maintained by Daniel Robbins, Gentoo's founder. It acts as a front-end to ssh-agent and gpg-agent, and will prevent your system from running multiple instances of these programs - just like the code snippet from my previous article did for ssh-agent. It also takes care of making the right variables available to other programs, so rsync can use the cached keys. It does, however, require some (minimal) setting up. If your keys require no user interaction (a blank passphrase), this should go in your ~/.bash_profile:
eval `keychain --eval id_dsa`

Do not do this if your keys require a passphrase - it will only cause your login session to hang. You will need to add the --noask option to run keychain upon login and still have to add the keys manually after that - in fact, I think it's better not to include keychain in your .bash_profile altogether in that case.

In the script that will be run through cron, you need to insert this line at the top:
eval `keychain --noask --eval id_dsa` || exit 1

In both cases, you need to replace id_dsa with the name of the key you want cached. There is no need to prefix it with ~/.ssh/, keychain will look there automatically.. The --noask option will tell keychain not to prompt for a new key to add, if it is an unattended operation that could cause the operation to stall until the system kills it, e.g. at shutdown.

This is how it looks (here keychain caches two of my keys):
[stijn@hermes ~]$ keychain id_rsa-amalthea id_rsa-bellerophon
* Initializing /home/stijn/.keychain/hermes-sh file...
* Initializing /home/stijn/.keychain/hermes-csh file...
* Initializing /home/stijn/.keychain/hermes-fish file...
* Starting ssh-agent
* Initializing /home/stijn/.keychain/hermes-sh-gpg file...
* Initializing /home/stijn/.keychain/hermes-csh-gpg file...
* Initializing /home/stijn/.keychain/hermes-fish-gpg file...
* Starting gpg-agent
* Adding 2 ssh key(s)...
Enter passphrase for /home/stijn/.ssh/id_rsa-amalthea:
Identity added: /home/stijn/.ssh/id_rsa-amalthea (/home/stijn/.ssh/id_rsa-amalthea)
Enter passphrase for /home/stijn/.ssh/id_rsa-bellerophon:
Identity added: /home/stijn/.ssh/id_rsa-bellerophon (/home/stijn/.ssh/id_rsa-bellerophon)
[stijn@hermes ~]$

This is how it looks when you call keychain again, with running instances and cached keys:
[stijn@hermes ~]$ eval `keychain --eval id_rsa-bellerophon`
* Found existing ssh-agent (25003)
* Found existing gpg-agent (25028)
* Known ssh key: /home/stijn/.ssh/id_rsa-bellerophon

Have fun with it :-)