Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

CentOS 5.4

(in my script file - script.sh)

#!/bin/bash
ssh 192.168.0.1 '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.

share|improve this question

3 Answers 3

up vote 3 down vote accepted

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

PATH=/bin:/usr/bin:/sbin
MYVAR=whatever

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 192.168.0.1

Now try the connection with

#!/bin/bash
PATH=/usr/bin

ssh -i /myprivatekey -l root 192.168.0.1 '/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.

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

#!/bin/bash
/usr/bin/ssh 192.168.0.1 '/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.

share|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 192.168.0.1 '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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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