Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Having a very strange problem. I've created a small bash script which runs a command on a remote host via ssh (using public key authentication).

When I run this script manually from the command line it works fine, but when placed in /etc/cron.hourly it fails with Permission denied, please try again. error.

  • I explicitly set the key in the script using ssh -i /root/.ssh/id_rsa user@remote "command";
  • the script is running as root (I added a echo `id` > /tmp/whoami.log to double-check); and
  • the ssh key is not password protected...

The system is Ubuntu 12.04 server, I don't have much access on the remote side to troubleshoot, but as I said, running ssh manually or the same bash script from the command-line works.

Any idea why this is happening or how to fix it??


turns out I was mistaken, and the ssh key was password protected (with keychain loading the ssh-agent), hence why it failed from a script but not when running from the bash session. Adding . ~/.keychain/$HOSTNAME-sh to my script resolved the problem (thanks to @grawity who pointed me in the right direction and provided a comprehensive answer).

share|improve this question
Are you sure running it manually uses that particular key? Test again after unsetting SSH_AUTH_SOCK and KRB5CCNAME environment variables. – grawity Aug 19 '12 at 14:17
Thanks for the suggestion. Not sure I understand you fully though. I am pretty sure it is using that particular key, because I am able to connect / run a command on the remote host when running manually. What exactly should I test again after unsetting those variables? – Yoav Aner Aug 19 '12 at 14:23
Also - I'm not using ssh-agent, so not sure how SSH_AUTH_SOCK is related (although I'm happy to try anything). I'm accessing the key file directly, and the key file is not password protected. As for KRB5CCNAME a quick search showed this is something to do with Kerberos. Again - don't see the connection to this problem, but maybe I'm missing something here... – Yoav Aner Aug 19 '12 at 14:26
Test your script, of course. You cannot be "pretty sure it is using that particular key" until you do so, because cron jobs run in a different environment than interactive commands. It would be even better if you added a -v option to that ssh command... – grawity Aug 19 '12 at 14:26
But I do so. I explicitly use the key using ssh -i command in both cases... I'll try unsetting those variables in the script and see. Good suggestion to add -v - I'll add it too. – Yoav Aner Aug 19 '12 at 14:27
up vote 5 down vote accepted

Interactive commands and cron jobs run in different environments – in particular, an interactive session might have a SSH agent running, or a Kerberos TGT stored. Because of the way ssh orders authentication methods, you cannot be sure that your key is used just because you added the -i option.

  • If a SSH agent is running, the ssh client always tries agent keys before using any explicitly-specified keys.

  • If the network uses Kerberos and a Kerberos TGT is present, OpenSSH will use it before trying public-key authentication.

I don't know anything about your environment, but both of these possibilities are easy to check:

  1. Add unset SSH_AUTH_SOCK and unset KRB5CCNAME before the ssh command, then manually run the modified script.

    This will prevent the script from seeing the agent or the Kerberos tickets, and will only use the explicitly-specified key.

  2. Add the -v option to ssh. This will display more detail on how the authentication happens.

You can also add -oIdentitiesOnly=yes to the ssh command; this will force it to use the specified key.

And if you add tips on accessing the agent from cron - even better

This is generally not recommended, since the agent is usually closely tied to your interactive login session. In particular, it's only started when you log in, and killed when you log out – and it needs your password to actually unlock the SSH keys (assuming they were password-protected).

You mentioned "Keychain" – is this the OS X program, or the Linux script? (I don't know much about the architecture of Mac OS X, but AFAIK it makes it much harder to access the user's ssh-agent from a cronjob...)

share|improve this answer
Thanks again @grawity. I forgot that I was using ssh-agent after all. Since I am already using keychain, adding this to my bash script resolved the problem: . ~/.keychain/$HOSTNAME-sh – Yoav Aner Aug 19 '12 at 15:30
keychain (also available as a package on debian/ubuntu). Yes, I'm aware of the security concern, but it's still safer than storing the ssh key without a passphrase, or placing the ssh password in the script. – Yoav Aner Aug 19 '12 at 16:22

Another workaround to this issue is set cron to ssh to the local box to in turn run the ssh command instead of running the file or command by its local, absolute path. This caches the KRB5CCNAME and works where /path/command does not.

# Fails:
0 * * * * /home/user/

# Works:
0 * * * * /usr/bin/ssh user@localhost /home/user/

# Works:
/usr/bin/ssh user@localhost /home/user/
share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .