bash: el uso de scp en el trabajo cron falla, pero se ejecuta con éxito cuando se ejecuta desde la línea de comandos

Estoy tratando de usar scp en un script bash ejecutado por cron (estoy ejecutando esto en Ubuntu 10.0.4 LTS).

El script funciona bien (es decir, transfiere y copia el archivo 1 y el archivo 2 desde / hacia el servidor remoto, cuando lo ejecuto desde la línea de comandos. Sin embargo, cuando ejecuto el script como un trabajo cron, falla.

Así es como se ve el guión:

#!/bin/bash

cd /home/oompah/scripts/tests/
scp -P 12345 file1 oompah@someserver.com:~/uploads

if scp -P 12345 oompah@someserver.com:/path/to/file2.dat local.dat >&/dev/null ; then 
    echo "INFO: transfer OK" ; 
else 
    echo "ERROR: transfer failed" ; 
fi

El mensaje de error que recibo (redirigido a un archivo de registro) cuando lo ejecuto como un trabajo cron es:

ERROR: transfer failed

El mensaje de error que recibo en mi bandeja de entrada de correo es:

Permission denied (publickey).
lost connection

¿Por qué está sucediendo y cómo puedo solucionarlo?

[Editar]

Modifiqué el primer comando scp con un comando -i (como lo sugirió M Jenkins), también agregué -v para mensajes de depuración. Aquí está el registro completo de mensajes de depuración. Con suerte, puede arrojar algo de luz sobre lo que está sucediendo:

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

Mi conjetura:

Tiene un par de claves SSH protegido por contraseña, que GNOME Keyring carga automáticamente cuando inicia sesión. Sin embargo, cronno tiene acceso al llavero y sshtampoco puede solicitar una contraseña (debido a la falta de tty).

Para citar el sshregistro que agregó:

debug1: clave pública de oferta : /home/oompah/.ssh/id_rsa
debug1: el servidor acepta la clave: pkalg ssh-rsa blen 277
debug1: PEM_ read_PrivateKey falló
debug1: lea la clave privada PEM realizada: escriba
debug1: read_passphrase: no se puede abrir / dev / tty : no existe tal dispositivo o dirección

Parece que scp no está recogiendo su par de claves pública / privada de su directorio ~ / .ssh.

Intenta agregar

HOME=/home/oompah

en la parte superior de su archivo crontab (ya debería estar configurando eso de todos modos automáticamente)

También podrías intentar agregar

echo "DEBUG: My home dir is $HOME"

en su script para asegurarse de que esté obteniendo el valor correcto.

Otra opción es especificar el parámetro -i a scp para forzar el uso de un par de claves específico:

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

por ejemplo.

¿Qué usuario está ejecutando cron? Parece que ese usuario no tiene acceso a su clave pública.

Aunque no es el problema en este caso, cron interpreta el signo de porcentaje ( %) como un carácter de nueva línea, por lo que debe escaparse ( \%) o terminará con la mitad de un comando preguntándose por qué cron simplemente no hace nada (aunque se quejará en syslog).

Esto puede causar problemas si está trabajando /bin/dateen su crontab.