bash: l'utilisation de scp dans le travail cron échoue, mais s'exécute correctement lors de l'exécution à partir de la ligne de commande

8

J'essaie d'utiliser scp dans un script bash exécuté par cron (je l'exécute sur Ubuntu 10.0.4 LTS).

Le script fonctionne correctement (c.-à-d. Transfère et copie les fichiers 1 et 2 vers / depuis le serveur distant, lorsque je l'exécute à partir de la ligne de commande. Cependant, lorsque j'exécute le script en tant que tâche cron, il échoue.

Voici à quoi ressemble le script:

#!/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

Le message d'erreur que j'obtiens (redirigé vers un fichier journal) lorsque je l'exécute en tant que tâche cron est:

ERROR: transfer failed

Le message d'erreur que je reçois dans ma boîte de réception est:

Permission denied (publickey).
lost connection

Pourquoi se passe-t-il et comment puis-je le réparer?.

[Éditer]

J'ai modifié la 1ère commande scp avec une commande -i (comme suggéré par M Jenkins), j'ai également ajouté -v pour les messages de débogage. Voici le journal des messages de débogage complet. Espérons que cela puisse éclairer ce qui se passe:

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

— oompahloompah
source

3

Quelle sortie obtenez-vous si vous ne redirigez pas stdout et stderr vers / dev / null?

— bmk

@bmk: sans la redirection stdout, je reçois les messages suivants: Autorisation refusée (publickey). perte de connexion Autorisation refusée (publickey).

— oompahloompah

Suggestion: ne jetez jamais stderr dans des scripts comme celui-ci. C'est plus utile que d'avoir un seul message "ERREUR".

— user1686

1

pourrait-il être que a.) vous utilisez un agent lors de l'exécution interactive de la commande, b.) vous l'exécutez en tant qu'utilisateur différent sans propre paire de clés (ou dossier de base) ou c.) que les touches autorisées sur la cible restreignent la source de la connexion ...?

— 0xC0000022L

7

Ma conjecture:

Vous disposez d'une paire de clés SSH protégée par mot de passe, qui est automatiquement chargée par le trousseau de clés GNOME lorsque vous vous connectez. Cependant, cronn'a pas accès au trousseau de clés et sshne peut pas non plus demander de mot de passe (par manque de tty).

Pour citer le sshjournal que vous avez ajouté:

debug1: Offrir la clé publique : /home/oompah/.ssh/id_rsa
debug1: Le serveur accepte la clé: pkalg ssh-rsa blen 277
debug1: PEM_ read_PrivateKey a échoué
debug1: lire la clé privée PEM effectuée: type
debug1: read_passphrase: impossible d'ouvrir / dev / tty : Aucun périphérique ou adresse de ce type

— user1686
source

@grawity: Merci pour l'information. Comment puis-je résoudre le problème?

— oompahloompah

@oompah: supprimez le mot de passe de votre paire de clés. (Si vous le souhaitez, vous pouvez en créer un deuxième uniquement pour une utilisation automatisée et le donner à scp -i.)

— user1686

@grawity: Merci pour les commentaires. Je ne suis pas à l'aise de supprimer un mot de passe de ma Keypair (je ne saurais pas comment faire de toute façon). Vous mentionnez la création d'une "deuxième" - vous voulez probablement dire une deuxième paire de clés - mais celle-ci sans mot de passe - afin que je puisse l'utiliser pour des connexions automatisées. BTW, tu veux dire PASSPHRASE quand tu dis mot de passe?

— oompahloompah

@oompah: Si votre machine CentOS est physiquement sécurisée, ça va. La deuxième suggestion de paire de clés ne sera probablement utile que si vous avez la paire de clés principale sur de nombreux systèmes. (OpenSSH l'appelle "phrase secrète", mais peu de gens utilisent réellement une phrase entière pour leurs clés.)

— user1686

J'ai finalement réussi à le faire fonctionner, après avoir beaucoup travaillé avec le trousseau, etc. Au final, je me suis contenté de vous suggérer de créer une paire de clés sans mot de passe pour cron et de la transmettre à scp dans le script shell. Ça ne devrait pas être vraiment dur ... SMH

— oompahloompah

3

Il semble que scp ne récupère pas votre paire de clés publique / privée dans votre répertoire ~ / .ssh.

Essayez d'ajouter

HOME=/home/oompah

dans le haut de votre fichier crontab (il devrait déjà être défini automatiquement de toute façon)

Vous pouvez également essayer d'ajouter

echo "DEBUG: My home dir is $HOME"

dans votre script pour vous assurer qu'il obtient la bonne valeur.

Une autre option consiste à spécifier le paramètre -i à scp pour forcer l'utilisation d'une paire de clés spécifique:

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

par exemple.

— Majenko
source

J'ai essayé votre suggestion (en utilisant l'option -i). S'il vous plaît voir ma question mise à jour

— oompahloompah

3

Sous quel utilisateur cron fonctionne-t-il? Il semble que cet utilisateur n'ait pas accès à votre clé publique.

— quantique
source

0

Bien que ce ne soit pas le problème dans ce cas, cron interprète le signe pour cent ( %) comme un caractère de nouvelle ligne, il doit donc être échappé ( \%) ou vous vous retrouverez avec une demi-commande se demandant pourquoi cron ne fait simplement rien (même s'il se plaindra dans syslog).

Cela peut causer des problèmes si vous travaillez avec /bin/datevotre crontab.

— Michael Trojanek
source