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

8

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).
ubuntu bash ssh cron scp oompahloompah
fuente
3
¿Qué salida obtienes si no redirige stdout y stderr a / dev / null?
bmk
@bmk: sin la redirección stdout, recibo los siguientes mensajes: Permiso denegado (clave pública). conexión perdida Permiso denegado (clave pública).
oompahloompah
Sugerencia: nunca descarte stderr en scripts como este. Es más útil que tener un solo mensaje "ERROR".
user1686
1
podría ser que a.) usa un agente cuando ejecuta el comando de forma interactiva, b.) lo ejecuta como un usuario diferente sin su propio par de claves (o carpeta de inicio) o c.) que las claves_autorizadas en el destino restringen la fuente del conexión ...?
0xC0000022L

Respuestas:

7

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

usuario1686
fuente
@grawity: Gracias por la información. ¿Cómo soluciono el problema?
oompahloompah
@oompah: elimine la contraseña de su par de claves. (Si lo desea, puede crear una segunda para uso automatizado y dársela scp -i)
User1686
@grawity: Gracias por los comentarios. No me siento cómodo eliminando una contraseña de mi Keypair (en cualquier caso, no sabría cómo hacerlo). Menciona la creación de un "segundo", presumiblemente se refiere a un segundo par de claves, pero este sin contraseña, por lo que puedo usarlo para inicios de sesión automatizados. Por cierto, ¿te refieres a la CONTRASEÑA cuando dices contraseña?
oompahloompah
@oompah: Si su máquina CentOS es físicamente segura, está bien. La segunda sugerencia de par de claves probablemente solo sea útil si tiene el par de claves principal en muchos sistemas. (OpenSSH lo llama "frase de contraseña", pero no muchas personas realmente usan una frase completa para sus claves.)
user1686
Finalmente conseguí que esto funcionara, después de mucho jugar con el llavero, etc. Al final, me decidí por su sugerencia de crear un par de claves sin contraseña para cron y pasarlo a scp en el script de shell. Realmente no debería ser tan difícil ... SMH
oompahloompah
3

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.

Majenko
fuente
Intenté su sugerencia (usando la opción -i). Por favor vea mi pregunta actualizada
oompahloompah
3

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

cuantícula
fuente
0

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.

Michael Trojanek
fuente