I am running a process from cron that tars up the local box and sends the result over ssh to a backup box. Therefore I require passwordless key based authentication.
You're probably better off using a key with no passphrase which is tied to a specific command on the remote server than using the ssh-agent (IMO). I wrote about this on the redhat-list the other day:
https://www.redhat.com/archives/redhat-list/2003-October/msg01039.html
Even if you decide that you want to use the agent, you should tie the key to just one command on the remote side, otherwise an attacker who could steal the private key could also just use the agent while it's running. Leaving an agent running on a box does not significantly improve the security of your ssh setup.
I have created a rsa key and copied my public key to another box. I am able to login to the local box and ssh to the other box without being asked for a password, so I know this part of the process works. Where the process falls down is when I run this from cron.
That's because cron jobs have a clean environment. They don't know where to find the ssh-agent socket. You can use "keychain" to correct that problem:
http://www-106.ibm.com/developerworks/library/l-keyc2/
The following shows the problem with ssh-agent.
[backup@Copper mason]$ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-XXbgea1j/agent.28462; export SSH_AUTH_SOCK; SSH_AGENT_PID=28463; export SSH_AGENT_PID; echo Agent pid 28463;
OK. You just started an agent, and failed to use the shell constructs it print out. You normally want to:
eval `ssh-agent`
or:
ssh-agent ./some-shell-script
In the former case, the current shell will get the variables set up properly. You'll have to terminate the agent manually when you're done. In the latter case, the variables will be available to the sub-script, and the agent will terminate after the script does.
[backup@Copper mason]$ cat /tmp/ssh-XXbgea1j/agent.28462 cat: /tmp/ssh-XXbgea1j/agent.28462: No such device or address
That'd be normal. You can't 'cat' a socket. You can use 'ls' to see if it exists, though.
[backup@Copper mason]$ echo $SSH_AUTH_SOCK /tmp/ssh-XXq0UhV0/agent.28400
Red Hat's default X sessions have an agent running. This variable was probably set by the agent that was started for your X session.
Notice that the value that $SSH_AUTH_SOCK gives does not match what ssh-agent says it is spitting out.
That's because it was set by a different agent.
-- Shrike-list mailing list Shrike-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/shrike-list
