You are not logged in.
Hi Forums,
I have a bash script which does some tasks on a remote server via ssh. The connection uses a private/public key without a passphrase as this seems to be the only way to connect via ssh in a cronjob. If I execute the script manually, then it works and connects to the remote server. If the script is run as cronjob, then it doesn't work and this error message appears in the crond log:
CMDOUT (ssh: Could not resolve hostname ###HOSTSNAME###: Name or service not known)The network connection is set up manually (not by DHCP) in the rc.conf and a nameserver entry in the resolv.conf. Could this be the reason or why else could the connection fail when executed as a cronjob?
Last edited by clownfish (2012-06-27 16:42:12)
Offline
How are you executing the cronjob exactly? Which user's crontab did you add it to? Seeing how it involves ssh keys, I'm assuming your own user, but just checking to be sure.
Burninate!
Offline
Cron doesn't use your existing shell environment unless you tell it to.
You should use something like keychain, ssh-agent, or gpg-agent. This allows you to maintain the security of having a passphrase while allowing you to source those keys for use in scripts and cronjobs. That way you just type in the passphrase once (at boot time, or another time of your choosing).
I use this snippet in .bashrc to ask to for passphrases if they aren't already cached:
### SSH and GPG KEY HANDLING ###
keys="logo_rsa web_rsa github_rsa"
if [ "$(hostname)" != 'homeserver' ];then
keys="$keys id_rsa"
fi
type -P keychain &>/dev/null || { echo "I require keychain but it's not installed. Aborting." >&2; }
eval $(keychain -q --eval $(echo "$keys"))Then to use in a cronjob or script, source the keys much the same way:
# Source SSH keys
type -P keychain &>/dev/null || { echo "I require keychain but it's not installed. Aborting." >&2; exit 1; }
eval `keychain --noask --eval --agents ssh id_rsa` || exit 1You can do this same thing with just ssh-agent or gpg-agent --- just takes a few more lines of code. Some googling and man page reading will lead you in the right direction ![]()
Scott
Last edited by firecat53 (2012-06-27 15:36:04)
Offline
Cron doesn't use your existing shell environment unless you tell it to.
Ahhhh, I already thought that this could be the reason, because another cronjob couldn't find /usr/bin/smartctl without /usr/bin.
Thanks for your scripts! I just wanted it to work any way, and to exclude the key as a source of failure, I left the passphrase blank. Your scripts will help me for sure to tighten it up and make it more secure. Is it right, that I have to login and enter the passphrase everytime I reboot the server?
@Gcool: As the script creates a backup of /etc, I need to run it from root's crontab. Or are there better solutions?
EDIT: @firecat53: The scripts just solve the issue about the keys without a passphrase. How can I tell this single cronjob to use the environment, or at least the network settings which I have set up for the regular users?
Last edited by clownfish (2012-06-27 16:33:10)
Offline
Yes, you will need to enter the passphrase each time you reboot...given I only reboot the server every couple of months, a small price to pay
I use keys for both root and my user, which need to be sourced separately. I login to root after a reboot and have the same snippet in /root/.bashrc to source the root users keys as well. Again, a bit of a pain, but more secure than passphrase-less keys.
Scott
Offline
No pain, no gain
I'm just worried that I forget to login for the passphrases if I only reboot the machine every now and then. I'll have to adjust the scripts so that they tell me, that the connection didn't work if I once forget about the passphrases.
Offline