Ssh keys problem

[Gordon Messmer]

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 at 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.