Anne Wilson wrote:
I want it to be able to do a scripted rsync when I'm busy with something else,
so keys seem the best answer - certainly preferable to having passwords in a
plain text file.
Yep, I do the same thing in a couple of places. To avoid using keys or
agents that could be badly misused, I do this:
1) On the source machine (where the rsync is initiated), create an ssh key:
$ ssh-keygen -t rsa
2) Assuming that I want to copy /export/example from the source host to
another, I'd set up a cron job that would run:
$ rsync -a -e ssh /export/example/ root@destination:/export/example/
3) On the destination host, I'd install the public key in the
.ssh/authorized_keys file with the rsync "server" command specified
(this should be just one line):
command="rsync --server -logDtpr . /export/example/" ssh-rsa
xxxxxxx-key-xxxxxx....
rsync is a complex example. You have to make sure that the arguments
match *exactly* on the source and destination hosts (adding the --server
arg to the destination host). Note that -logDtpr is the same as -a.
Most uses are more simple than that. If you're going to ssh to a
machine to invoke any command, you can specify it in the command=""
syntax rather than using an unrestricted key and specifying the command
at the client. This process makes sure that if an attacker gets your
key, he's only able to run the specific commands that the destination
host is configured to allow. You should name your keys in such a way as
to tie them to the command, logically, because you'll need one per
automatic job that you create.
This offers a very high level of defense, as opposed to creating either
unrestricted keys, or using an untended ssh-agent (possibly with
keychain). In either of those scenarios, if an attacker gets the client
host, he'll have unrestricted access to the destination as well.
