ssh Permission denied only in cron job

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??

update

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

Solution 1:

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

Solution 2:

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

#!/bin/bash
# Works:
unset SSH_AUTH_SOCK
unset KRB5CCNAME
/usr/bin/ssh user@localhost /home/user/sshscript.sh

Solution 3:

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