rsync par Cron: permission denied

J’ai été confronté à un étrange problème sur certaines machines en Ubuntu 12.04 (precise) pour lequel je vous livre ma solution de contournement. Ce n’est pas transcendant, mais ça fonctionne en attendant d’en savoir plus ou de trouver une autre solution.An_rsync_Primer

S.O.S.s.h.

J’ai des dossiers que je synchronise avec ou depuis un serveur distant en utilisant rsync, principalement pour faire des sauvegardes. Ces commandes rsync sont intégrées dans des scripts que j’utilise depuis plusieurs années sans problème. Pour pouvoir éviter les problèmes de droits, ces scripts sont lancés par le cron du root.
La commande qui nous intéresse est de cette forme:
rsync -avP dossier/local manu@serveur:/dossier/distant/ > /tmp/monlog.log 2>&1

Et le root peut se connecter au serveur sans mot de passe par échange de clef ssh.

Or, depuis quelques temps, impossible de faire la sauvegarde. Les logs contiennent quelque chose comme ceci:

Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]

Alors que lorsque le programme est lancé en root depuis un terminal, il fonctionne sans erreur! (Donc pas de problème de droits d’accès aux dossiers/fichiers)

Environnement variable ou Variables d’environnement

Le cron n’ouvre pas un véritable shell lorsqu’il lance une action programmée, et les variables d’environnement utilisées dans une console ne sont pas toutes présentes. C’est peut être l’une des raisons du problème.

Sur certains forums, on a parlé de SSH_AUTH_SOCK et de SSH_AGENT_PID, mais je n’ai pas réussi à les faire prendre en compte pour résoudre le problème…

Où est la clef?

Qu’importe, indiquons à ssh qu’on veut utiliser la clef qui nous permet de s’identifier sur le serveur

rsync -avP -e "ssh -l root -i /root/.ssh/id_rsa" dossier/local manu@serveur:/dossier/distant/ > /tmp/monlog.log 2>&1

Et? Pas mieux, toujours rejeté par le serveur…

Qui me parle ?

Comme les logs du serveur n’indiquaient pas d’informations utiles, il faut demander à rsync d’être plus bavard

rsync -avvvv -e "ssh -l root -i /root/.ssh/id_rsa" dossier/local manu@serveur:/dossier/distant/  > /tmp/monlog.log 2>&1

Du coup, ça donne quelques indications dans le log:

opening connection using: ssh -l root -i /root/.ssh/id_rsa -l manu serveur rsync --server -vvvvue.Lsf . /dossier/distant/
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).

Ahhhh! Pourquoi il me met un -l manu alors que je lui ai spécifié -l root ?
Eh bien je ne sais pas, mais c’est la source du problème: identifié en tant que manu, il ne peut donc plus accéder à la clef ssh du root.

Comme je suis vicieux et mauvais perdant, j’ai essayé d’accéder à la clef de manu:

rsync -avvvv -e "ssh -l root -i /home/manu/.ssh/id_rsa" dossier/local manu@serveur:/dossier/distant/  > /tmp/monlog.log 2>&1

Et ça marche! Parce que le root peut entrer partout et lire les clefs de tous les utilisateurs (et surtout parce que manu aussi peut s’identifier en ssh sur le serveur sans mot de passe)

Et les droits d’accès aux dossiers ? Pas de problème, c’est toujours root (par l’intermédiaire du cron) qui lit les fichiers, mais il n’utilise pas sa propre clef et se fait passer pour manu dans le rsync.

Carpe diem

Pour résumer:

  • Plein de personnes ont rencontré le même problème, mais aucune solution proposée n’a fonctionné pour moi
  • Tout se passe comme si rsync refusait d’utiliser la clef du root
  • On peut utiliser la clef de n’import quel utilisateur, tant qu’il peut accéder au serveur. Au besoin, créer un utilisateur dédié.
  • C’est pénible, il faut que je modifie mes scripts qui me permettaient d’unifier la méthodologie
  • Bug ou pas bug ? Je ne sais pas.
  • Résolu? Je ne suis pas sûr. J’aimerai comprendre pourquoi sur certaines installations ça fonctionne, et pas sur d’autres, d’autant que j’essaye d’avoir des configurations logicielles le plus identiques possibles pour en simplifier la gestion.

En tous cas, si vous avez des infos sur ce changement de comportement, ou sur le moyen de fonctionner à l’ancienne mode, n’hésitez pas à laisser une bafouille.

Changer un mot de passe Windows sans le connaitre

Il arrive qu’on doive accéder à un ordinateur Windows mais qu’on ne connaisse pas le mot de passe ou qu’on l’ait oublié… Dans mon cas, j’utilise tellement peu le serveur de test que le mot de passe m’est sorti de l’esprit.

Heureusement, il est possible de le modifier sans avoir à tout réinstaller!

De plus, l’aide nous vient de GNU/linux et des outils libres par ntpasswd (par l’intermédiaire de ntfs-3g et busybox)

Il suffit de graver l’iso et de démarrer l’ordinateur sur le CD pour obtenir un prompt de style MSDOS, de sélectionner la partition d’installation de windows.

Ensuite, il faut préciser le chemin d’accès à la base de registre (\windows\system32\config pour XP) et presser Enter. Puis choix 1 Edit user data and password.

Entrez l’utilisateur dont vous voulez modifier le mot de passe et saisissez le nouveau mot de passe.

Vous pouvez modifier tous les comptes de la machine, administrateur compris. Sortez et validez par Y pour enregistrer les modification, puis redémarrez normalement.

Un outil pratique qui nous rapelle qu’un système d’exploitation protégé par mot de passe ne l’est (protégé) QUE si l’ordinateur qui le fait tourner est sécurisé (mot de passe au BIOS, démarrage sur le disque dur en premier, boitier de ordinateur fermé à clef et ordinateur inaccessible), sinon, n’importe qui pourrait modifier votre mot de passe et vous empêcher d’avoir accès à vos données.

Dans mon cas, c’est une réinstallation complète de windows qui m’a été évitée, et ça, ça n’a pas de prix!

Note: cet outil permettant d’accéder à la base de registre, il est possible de faire bien d’autres choses que de modifier le mot de passe (ajout/modification/suppression de clefs). Pratique pour supprimer cet antivirus nommé comme une bonne marque de moto et qu’il est difficile (voire pénible) de supprimer correstement pour mettre un bon anti virus.