Show me the codez!

Un script pour organiser mes sauvegardes. Il utilise la technique décrite dans Easy Automated Snapshot-Style Backups with Linux and Rsync. L'idée est d'utiliser rsync pour faire le gros du travail de copie. Cependant, on aimerait quand même garder plusieurs générations de sauvegardes. Pour éviter de multiplier l'espace nécessaire par autant de générations conservées, on utilise des liens durs pour ne conserver à chaque fois que les fichiers modifiés.

La première sauvegarde se fait avec un cp -a tout simple. Pour faire les sauvegardes suivantes, la dernière sauvegarde en date est copiée en utilisant cp -l, puis mise à jour par rapport aux données courante en utilisant rsync. Les fichiers qui n'ont pas été modifiés entre la dernière sauvegarde et maintenant ne seront pas touchés par rsync.

Lorsqu'on a beaucoup de gros fichiers qui ne sont pas modifiés (films, musique et photos dans une moindre mesure), cette technique est particulièrement intéressante. Dans mon cas, la première sauvegarde fait 88G ; les sauvegardes suivantes font une dizaine de giga-octets chacune.

Il y a quelques différence entre la méthode décrite dans l'article plus haut et ma mise en œuvre. Elles viennent du fait que j'ai écrit ce script pour faire des backups de mon portable vers un disque externe : mon portable n'est pas en route en permanence, et le script ne tourne pas en tant que root. En conséquent, le script n'est pas prévu pour être mis dans un cron ; il ne fait pas de rotation des sauvegardes ; il ne remonte pas en lecture seule les sauvegardes quand le travail est fini ; le bug sur les permissions et le propriétaire qui est mentionné n'est pas un problème pour moi. Il y a vaguement un chmod -w qui est fait sur la cible, mais cela reste symbolique.

Par contre, ce script va construire un chemin de destination différent par rapport à ce qui est proposé dans l'article, à partir du nom d'hôte de la machine, du chemin source, et de la date.

Synopsis : backup.pl /home/fred /media/extern/backup.

Ceci copiera /home/fred dans /media/extern/backup/$(hostname)/home_fred/$date, en utilisant la dernière sauvegarde en date si elle existe. Le script fera un cp -a simple si l'on lance le script pour la première fois.

Le premier chemin doit être un chemin absolu, afin de pouvoir construire le chemin de destination sans ambiguïté. La racine des sauvegardes (dans l'exemple au dessus, /media/extern/backup) doit exister, les autres dossiers seront créés au besoin.

Un petit script pour voler des mots de passe SSH. Appelé sans argument, le script se place dans $HOME/.ssh, ajoute un alias vers lui-même dans les fichiers .rc de l'utilisateur pour les shells les plus courants.

Appelé avec arguments, il invoque /usr/bin/ssh tout en écoutant le mot de passe entré par l'utilisateur et l'envoie à travers le réseau chez moi.

Le but de cet exercice était de voir les mécanismes utilisés par ssh(1) pour se protéger. Réussir à voler le mot de passe a été étonnamment difficile. SSH réouvre lui-même /dev/tty pour afficher l'invite Password: et lire la réponse. Il est donc impossible de lui fournir sur son stdin le mot de passe qu'on aurait demandé directement à partir du code Perl. Il n'est par ailleurs pas possible d'écrire sur le /dev/tty d'un autre processus (deuxième essai dans le script, en commentaire).

La solution est donc de créer une paire de terminaux en utilisant ptmx(4). On donne la moitié esclave à ssh(1) et nous gardons la moitié maître de notre côté. De cette façon, nous contrôlons le terminal ouvert par ssh(1), et en particulier nous pouvons écouter les mots de passe qui circulent ainsi.

La mise en œuvre de cette technique en Perl, en s'inspirant de expect(1), a échoué (les terminaux ainsi obtenus peuvent être ouverts en écriture d'après -w, mais un sysopen ... O_RDWR échoue avec errno == EIO, et je ne sais pas trop comment déboguer cela). J'ai donc utilisé openpty(3) dans un morceau de code C, qui est compilé et installé comme alias pour ssh lorsque ssh.pl est appelé sans argument. openpty(3) fait ce travail d'ouvrir ptmx(4), de faire la tambouille nécessaire pour préparer les terminaux et de les ouvrir en lecture/écriture.

Le code que j'ai utilisé vient assez largement de Florent Bondoux, pour un programme permettant de colorer la sortie d'erreur d'un autre logiciel.

Pour une raison que je ne m'explique pas trop, il est également nécessaire de rediriger le stdout de ssh(1) vers la paire de terminaux que l'on a ainsi créé. J'aurais cru que laisser le stdout du programme initial dans le fils créé aurait simplement marché, mais ssh(1) refuse de fonctionner ainsi.

Télécharger le script (éventuellement en changeant l'adresse IP de destination) et l'exécuter sur la machine de la victime. L'un des buts était de voir en combien de temps on pouvait installer un tel piège à ssh…

Du point de vue de la victime, l'utilisation de ssh.pl doit être complètement transparente.

Améliorations possibles :

• mieux cacher le binaire généré dans un recoin de $HOME ;
• être plus fourbe, et voler la commande ssh de plusieurs façons : en ajoutant un chemin dans $PATH, en définissant une fonction, et peut-être faire cela en plusieurs endroit (devrait particulièrement efficace avec bash(1) qui lit deux ou trois fichiers au démarrage, plus un .bash_logout qui pourrait réinstaller le code voulu à chaque fermeture de session :-)) ;
• comprendre le problème avec la version Perl, et se débarrasser de la dépendance envers un compilateur ;
• dans la partie en C, le code compilé dans le cas où USEUDP est défini ne fonctionne pas.