It took me some time to figure this one out, as everybody is using rsync and ssh-keys without passphrases, but I insist that an ssh-key should have a passphrase.
In my first attemts I got this error messages mailed to me by crontab:
Permission denied (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).Here are the steps to automate a backup initiated from crontab using rsync, SSH and ssh-keys with a passphrase:
. /home/username/.ssh/variables
rsync -avz --delete /data/ example.com:dataSSH_AUTH_SOCK=/tmp/ssh-DmFcb18036/agent.18036; export SSH_AUTH_SOCK;
SSH_AGENT_PID=18037; export SSH_AGENT_PID;
echo Agent pid 18037;That should do it for you, as it works like a charm for me!
| About | Consultancy | Articles | Contact |
|
|
|
|
|
| References | Red Hat Certified Architect | By Robert de Bock | Robert de Bock |
| Curriculum Vitae | By Fred Clausen | +31 6 14 39 58 72 | |
| By Nelson Manning | [email protected] |
Comments
If you're doing this on your
If you're doing this on your workstation, then you will need to change the variables at every logon, so this may work better :
PID=$(pgrep -fo bash)for i in $(strings /proc/$PID/environ); do
(echo $i | grep SSH) && export "$i"
done
Essentially, it's grabbing the environemtn variables from another bash process.
it's a very good solution. I
it's a very good solution. I am only wondering about the PID if I should reedit the file to update it. isn't and id that should change over reboots?
That is correct; if a machine
That is correct; if a machine reboots, that process (ssh-agent) is gone, so you'd have to add the key again after a reboot.
Most people take an ease approach; just don't give a passphrase to the key. But; it's a little less secure.
Thanks for your feedback!