crontab para executar o script bash (comando ssh nele) não está funcionando

Question

CentOS 5.4

(no meu arquivo de script - script.sh)

#!/bin/bash
ssh 192.168.0.1 'iptables -L' > /tmp;

(em / etc / crontab)

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

Se eu executar o script no terminal, as coisas funcionam bem. Mas use crontab para executá-lo, o tmp será gerado, mas não há nada no arquivo tmp (0k). Eu já rodei o agente ssh, então o ssh não perguntará a senha. Qual poderia ser o problema com isso? Obrigado.

    

Answer 1

Sugiro que você sempre defina explicitamente todas as variáveis necessárias no início dos scripts.

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

Dito isto, eu faria

1. crie um par de chaves privado / público
2. definir uma senha vazia na chave privada
3. definir permissão 400 no arquivo de chave privada
4. coloque a chave pública no arquivo authorized_keys do usuário root em 192.168.0.1

Agora tente a conexão com

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

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

Edit: Eu imaginei que o comando "iptables" tinha que ser executado pelo root no servidor remoto. Se não for, é claro que o parâmetro "-l" deve ser alterado de acordo.

    

Answer 2

Coisas que não serão executadas no cron, mas serão executadas a partir do terminal, são quase sempre um problema devido à diferença no ambiente. Você deve usar o caminho completo para seus executáveis e definir explicitamente quaisquer variáveis de ambiente e PATH que eles precisam.

#!/bin/bash
/usr/bin/ssh 192.168.0.1 '/sbin/iptables -L' > /tmp/output.$$

A propósito, você não tem realmente o seu script no diretório raiz?

Além disso, /tmp é um diretório que já deveria existir. Você deve criar sua saída como um arquivo dentro dela, como eu mostrei.

    

Answer 3

Eu não acho que o ssh-agent vá ajudar neste caso porque o cronjob não é um subprocesso de um que tenha os parâmetros de comunicação ssh-agent em seu ambiente. Você precisará configurar um login sem senha para que isso funcione.

Uma maneira de obter mais informações é alterar sua chamada ssh para

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

para que 1) o ssh produza uma saída de depuração detalhada no stderr e 2) o stderr seja redirecionado junto com o stdout. Esse arquivo de saída. $$ deve ter mais informações sobre o que está acontecendo ... minha aposta é, como eu disse, na falta de permanentes para abrir sua chave.