On Friday 10 October 2003 19:30, Gordon Messmer wrote: > MKlinke wrote: > > I haven't tried it with crontab so I don't know if it'll fit here > > but with batch jobs like this via ssh the ssh-agent mechanism works > > very well. The thought of null passphrases just leave me a little > > cold and shivering .... > > As well it should. There is a more secure option, though. It's > possible to tie an SSH key to a specific command on a remote server, > so that if the private key is stolen, it can only be used to execute > the configured command. > > For instance, when you run rsync over ssh, the local rsync command > spawns an ssh session and runs rsync on the remote end. If you were > to issue the local command: > rsync -av -e ssh /home/data/ server.example.com:/home/data/ > then the command executed on the server would be: > rsync --server -av . /home/data/ > > Notice that the arguments on the server side are basically the same > as on the local side (mostly... I fibbed a little. rsync on the > server actually gets the expanded options, equivalent to -a). > > Now, if you want this to happen at a regular interval, you might > create an ssh key pair, and name the private file > "id_rsa-rsync-data". You would then install the key on the server > side by editing the appropriate authorized_keys file, and putting the > command before the key: > > command="rsync --server -av . /home/data/" ssh-rsa <key> > > You'd then set up the cron job on the local side to use that private > key: > > rsync -av -e 'ssh -i id_rsa-sync-data' /home/data/ \ > server.example.com:/home/data/ > > Using this configuration, if the private key is stolen, the attacker > can only use rsync to modify the contens of /home/data on your > server. It can't be used for login shells. It may still be > dangerous, and you should still try to avoid running remote commands > as root, but it's a huge step up from using a key with no passphrase > to execute arbitrary commands on a remote server. Ah! Thankyou Gordon, this was on my short list of ssh variations to put in my toolkit. A good explanation to give me a little kick-start is quite a help! Regards, Mike Klinke -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
