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).

  • Are you sure running it manually uses that particular key? Test again after unsetting SSH_AUTH_SOCK and KRB5CCNAME environment variables. Aug 19, 2012 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, 2012 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, 2012 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... Aug 19, 2012 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, 2012 at 14:27

4 Answers 4


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...)


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/sshscript.sh

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

# Works:
/usr/bin/ssh user@localhost /home/user/sshscript.sh

You can use ssh-cron to set up scheduled SSH connections to secure servers without exposing your SSH keys, but using SSH agent.

  • The dependencies aren't available on Homebrew, so installing seems to be complicated. Passwordless key I guess… :-/ Aug 18, 2016 at 6:52

you can run your script or command in crontab like:

0 * * * * bash -c -l "/home/user/sshscript.sh"


0 * * * * bash -c -l "ssh root@yourhost 'echo $HOSTNAME'"

  • 2
    OP is already trying to run the script via cron; so this doesn't really seem to provide an answer.
    – bertieb
    Feb 23, 2017 at 8:14

You must log in to answer this question.

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