Archives de Tag: Rsync

RSYNC over SSH

par

0

Logs d’erreur RSYNC / SSH

Permission Denied ou read_passphrase: can’t open /dev/tty: No such device or address

Hello,

Je viens de résoudre ce souci qui m’a bien occupé..

Impossible de se connecter en RSYNC over SSH sur un host distant, malgré avoir stipulé l’ « identity_file » pour SSH…
Rien n’y fait … Rsync me dit « permission denied » et ssh m’indique « read_passphrase: can’t open /dev/tty: No such device or address »

Mais je suis tombé sur un thread qui expliquait que la crontab avait son propre environnement qui n’était pas celui de root (je savais déjà cela mais j’avais pas percuté que c’était encore plus vrai lorsqu’il s’agit de variables d’environnement impliquant le comportement de SSH) … or mes échanges de clés SSH se font avec PassPhrase … donc si environnement différent et bien mon RSYNC over SSH attend une passphrase qui ne peut être saisie => les infos de debug de SSH indiquent d’ailleurs l’erreur 

"debug1: read_passphrase: can't open /dev/tty: No such device or address"

=> Bah oui pas de TTY = pas de passphrase = pas autorisé

Sur ma machine j’utilise « Keychain » histoire d’avoir l’agent SSH de lancé afin de ne pas avoir à ressaisir la passphrase à chaque fois que je tente une connexion remote. Keychain génère un fichier qui contient les informations suivantes

SSH_AUTH_SOCK=/tmp/ssh-PWg3yHAARGmP/agent.18891; export SSH_AUTH_SOCK;
SSH_AGENT_PID=18893; export SSH_AGENT_PID;

==> La commande SSH-AGENT retourne les mêmes infos.

Donc, au final ce sont ces infos liées à la session en cours qui permettent les futures authentifications de la session en cours, sans nécessité de rerentrer la passphrase car déjà fait préalablement et mémorisée …


==> La solution est là !!! :

Il suffit dans le script lancée par la crontab, et de « sourcer » le fichier contenant ces informations ou de le faire sur la ligne de commande ds la crontab …

Exemple : 

14 09 * * * . /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh foo@my-server.fr:. >> /var/log/check_connexion.log 2>&1

ou utilisation de la commande

"source /home/foo/.keychain/foo.serveur.org-sh"

dans le script qui lance un connexion utilisant le SSH.

=> Avec ce sourcing, plus de souci. Les informations de SSH_AUTH_SOCK et SSH_AGENT_PID sont chargées dans l’environnement de la Crontab et sont donc connues, le RSYNC over SSH se passe alors sans souci.

Ca m’a bien occupé mais voilà, ça fonctionne 🙂