CentOS 5.4

(in my script file - script.sh)

ssh 'iptables -L' > /tmp;

(in /etc/crontab)

30 21 30 9 * root /bin/bash /script.sh

If I run the script in terminal, things work just fine. But use crontab to run it, the tmp will be generated, but there's nothing in the tmp file (0k). I already run ssh agent so ssh won't prompt to ask password. What could be the problem with this? Thanks.


I suggest you to always explicitly set all needed variables at the beginning of the scripts.


That said, I would

  1. create a private/public keypair
  2. set an empty password on the private key
  3. set permission 400 on the private key file
  4. put the public key in the authorized_keys file of the root user on

Now try the connection with


ssh -i /myprivatekey -l root '/sbin/iptables -L' > /tmp/output.$$

Edit: I guessed that the "iptables" command had to be executed by root on the remote server. If it is not, of course the "-l" parameter has to be changed accordingly.

| improve this answer | |
  • set empty pwd on the private key makes everything works. But this solution yields security concerns. Since now the private key can be use for anyone. – Stan Oct 1 '10 at 18:42
  • 1
    not exactly. please see step #3: properly set the permissions, so that the file can only be read by the owner – marcoc Oct 1 '10 at 18:53

Things that won't run from cron but will run from the terminal are almost always a problem due the difference in environment. You should use the full path to your executables and explicitly set any environment variables and PATH that they need.

/usr/bin/ssh '/sbin/iptables -L' > /tmp/output.$$

By the way, you don't really have your script in the root directory do you?

Also, /tmp is a directory that should already exist. You should create your output as a file within it as I've shown.

| improve this answer | |
  • thanks for the reply. I didn't put the script under root dir, it's just an bad example... – Stan Oct 1 '10 at 6:04
  • I use full path already, but still not working. Is there any other way to check? – Stan Oct 1 '10 at 6:09

I don't think ssh-agent is going to help in this case because the cronjob isn't a subprocess of one that has the ssh-agent communication params in its environment. You'll need to set up a passwordless login for this to work.

One way to get more info is to change your ssh call to be

ssh -vvv 'iptables -L' 2>&1 > /tmp/output.$$

so that 1) ssh will produce verbose debugging output on stderr and 2) stderr will be redirected along with stdout. That output.$$ file should have more info about what's going on... my bet is, as I said, on lack of perms to open your key.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.