bash: o uso do scp no job cron falha, mas é executado com sucesso quando executado a partir da linha de comando

Question

Estou tentando usar o scp em um script bash executado pelo cron (estou executando isso no Ubuntu 10.0.4 LTS).

O script funciona bem (isto é, transfere e copia file1 e file2 para / do servidor remoto, quando eu o executo a partir da linha de comando. No entanto, quando executo o script como uma tarefa cron, ele falha.

É como é o script:

#!/bin/bash

cd /home/oompah/scripts/tests/
scp -P 12345 file1 [email protected]:~/uploads

if scp -P 12345 [email protected]:/path/to/file2.dat local.dat >&/dev/null ; then 
    echo "INFO: transfer OK" ; 
else 
    echo "ERROR: transfer failed" ; 
fi

A mensagem de erro que recebo (redirecionada para um arquivo de log) quando a executo como uma tarefa cron é:

ERROR: transfer failed

A mensagem de erro que eu recebo na caixa de entrada do meu e-mail é:

Permission denied (publickey).
lost connection

Por que isso está acontecendo e como posso corrigi-lo?

[Editar]

Eu modifiquei o primeiro comando scp com um comando -i (como sugerido por M Jenkins), eu também adicionei -v para mensagens de depuração. Aqui está o log de mensagens de depuração completo. Espero que isso possa esclarecer o que está acontecendo:

Executing: program /usr/bin/ssh host 12.34.56.78, user oompah, command scp -v -t ~/uploads
OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 12.34.56.78 [12.34.56.78] port 12345.
debug1: Connection established.
debug1: identity file /home/oompah/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu3
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[12.34.56.78]:12345' is known and matches the RSA host key.
debug1: Found key in /home/oompah/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/oompah/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: No more authentication methods to try.
Permission denied (publickey).
lost connection
Permission denied (publickey).

    

Answer 1

Meu palpite:

Você tem um par de chaves SSH protegido por senha, que é automaticamente carregado pelo GNOME Keyring quando você faz o login. No entanto, cron não tem acesso ao chaveiro e ssh também não pode pedir uma senha (devido à falta de um tty).

Para citar o ssh log que você adicionou:

debug1: Offering public key: /home/oompah/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type
debug1: read_passphrase: can't open /dev/tty: No such device or address

    

Answer 2

Parece que o scp não está pegando seu par de chaves pública / privada do seu diretório ~ / .ssh.

Tente adicionar

HOME=/home/oompah

no topo do seu arquivo crontab (ele já deve estar configurado de qualquer maneira automaticamente)

Você também pode tentar adicionar

echo "DEBUG: My home dir is $HOME"

no seu script para se certificar de que está obtendo o valor correto.

Outra opção é especificar o parâmetro -i para scp para forçar um par de chaves específico a ser usado:

scp -i /home/oompah/.ssh/id_rsa ...

por exemplo.

    

Answer 3

Qual usuário está executando o cron? Parece que esse usuário não tem acesso à sua chave pública.

    

Answer 4

Embora não seja o problema neste caso, o cron interpreta o sinal de porcentagem ( % ) como caractere de nova linha, então ele precisa ser escapado ( \% ) ou você terminará com metade de um comando perguntando por que O cron simplesmente não faz nada (apesar de reclamar no syslog).

Isso pode causar problemas se você estiver trabalhando com /bin/date no seu crontab.