Journal [Rexp] Fini la bricole à base de ruban adhésif et de post-its

Sommaire

• Introduction
  • Remerciements
  • Description du problème
  • Environnement
  • Contraintes
  • Message important
• Gestion des backups
  • Configuration
  • Automatisation
• Gestion des mots de passe
  • Installation
  • Configuration
  • Ajout, synchronisation
  • Petites touches finales
• Conclusion et reste à faire

Cher nour 'jal¹,

En ce jour pluvieux d'été (y'a plus de saison maintenant, tu sais), je me suis dit que tant qu'à rester au chaud (comme d'hab' depuis quelques temps, oui, merci de me le rappeler), j'allais te compter mes dernières aventures.

Je sais, il n'y a pas grand chose de nouveau, que tu te dis déjà que ça va être triste à mourir d'ennui, que ça va être beaucoup de blablabla, et j'ai hésité à te raconter cette ensemble de petites choses à cause de ça.

Mais même si tu ferme un œil lors des parties peut-être un peu longues que tu connais déjà, l'objectif est de te montrer une solution complète pour résoudre les problèmes que j'avais, tout en réutilisant au maximum les bouts d'info glanés ici ou là (surtout ici, d'ailleurs), et ce en peu de temps au final.

Oui, tu lis bien, c'est un retour all-in-one que je m'apprête à te faire, parce que toi aussi, tu peux le faire, c'est pas si sorcier !

Allons-y, si tu veux bien.

C'est l'histoire d'un informaticien…

Introduction

Remerciements

Merci aux nombreux contributeurs de linuxfr qui ont, à leur manière, incité à ce retour d'expérience. Merci à l'équipe qui encourage à faire ce genre de retours. Et merci à ceux qui liront ce pavé de ne pas hésiter à me questionner, critiquer, proposer des pistes d'améliorations ou solutions alternatives (j'avoue très sincèrement ne pas avoir tenté de faire un comparatif).

Description du problème

…qui utilisait du scotch et des post-its. Enfin, c'est une façon de parler.

Par ((très) mauvaise) habitude, je faisais mes sauvegardes à coup de tar, du ruban adhésif donc (oui, c'est un poil tiré par les cheveux), et mes mots de passe étaient notés sur des post-it (quand même pas, mais la situation était proche).

Chaque jour était rythmé par un doux "Allez, aujourd'hui, je me lance, ça m'a l'air jouable d'après les incantations que j'ai entendu des incantations de grands savants !"

Mais en fait, je n'en savais trop rien, et surtout ni trop quoi et ni comment. Et la journée se finissait donc inlassablement par le sempiternel "Ok, là, je crois que j'ai compris, je verrai ça demain…"²

Je savais que je faisais mal, mais c'est tout, et aucune idée de par où je voulais aborder le problème. Juste que je voulais le faire. Pas forcément super bien, au top du nec plus ultra de la modernitude, mais le faire.

Environnement

État des lieux du "parc" informatique : deux machines sous linux (un fixe et un laptop, en debian stable), et un NAS sous une forme d'unix propriétaire.

Bon, c'est homogène, donc ça ne va pas trop poser de problème. Tout ce petit monde est dans le même LAN avec IP fixes, ce qui rend les choses simples aussi. Peu de chances de se lancer et de tomber sur un hic aux 3/4 du chemin.

J'utiliserai le fait que le NAS soit un unix à un moment, mais ce n'est même pas vraiment utile au final³. Ça facilite les choses, c'est tout.

Contraintes

Face aux nombreuses solutions à disposition, parfois propriétaires, d'autres juste click-click, d'autres encore en version alpha, il y en avait trop pour décider quoi que ce soit (le revers de l'homogénéité, quelque part) donc j'ai inversé le problème. On pose les contraintes, et on regarde ce qu'il reste.

Je voulais :

• que ce soit accessible en ligne de commande,
• que ça soit facilement installable,
• que la sauvegarde soit facilement automatisable et concerne seulement les données d'un utilisateur,
• synchronisable entre machines (pour la gestion des mots de passe),
• avec peu de configuration,
• reposant sur des outils éprouvés,
• avec un minimum de sécurité (plus qu'un tar.gz tout moisi basique, quoi),
• de préférence open-source,
• si possible partageant un socle commun, éventuellement déjà plus ou moins connu.

La "wish-list" est un peu longue, mais me semble raisonnable.

Pour le socle commun, je me suis dit que comme je connaissais déjà un petit peu ssh et gpg, se baser la dessus pour la sécurité serait pas mal (mais même si on n'a jamais utilisé, ça me semble abordable).

Du coup, j'ai retenu, plus ou moins à l'instinct :

• duplicity pour les backups,
• gopass pour la gestion des mots de passe.

Pour gopass, ce qui m'a attiré, c'est qu'il repose sur git pour la synchronisation.

Il n'est pas forcément nécessaire de connaître git, simplement savoir créer un compte et un nouveau projet privé sur gitlab (par exemple) peut suffir, l'usage de git est masqué.

Enfin, connaître peut-être utile quand même : je suis un peu sorti des clous et ai utilisé une fonctionnalité en beta, suite à une action un peu trop rapide, et ça m'a aidé à m'en sortir sans purger la configuration et refaire les quelques étapes pour revenir à l'endroit où j'ai raté une marche.

Message important

Le tout, c'est d'être calme, et d'y aller lentement, surtout si on ne connais pas bien ou qu'on appréhende un peu les outils barbares que sont ssh, gpg ou git. Pour gpg, il faut la version 2 pour gopass.

Ne pas hésiter à prendre des notes pour bien identifier quelle clef correspond à quoi (parce que oui, j'en ai généré un petit paquet en mode en veux-tu, en voilà). Ça, ça a été une de mes erreurs avec gopass, je me suis emmêlé les moufles⁴ entre les clefs pour les backups et pour les mots de passe et les machines associées, du coup, en cherchant à réparer le bazar, je me suis aventuré en beta.

Bref, faisez gaffe, en y allant molo, tout se passe tranquillou. Et puis c'est pas un terminal qui fait peur, hein ? (Hein ? gloups… Confiance ! ;) ).

La suite

Les deux sections suivantes n'ont pas d'ordre de dépendance. L'un fonctionne sans l'autre, et inversement.

J'ai fait les deux (trop) en même temps à cause du socle commun : j'ai choisi de séparer les clefs plus pour plus de flexibilité, et tant
qu'à faire d'en générer un bon petit lot, autant tout faire tant que c'est chaud.

Gestion des backups

Ici, l'installation est complètement basique : c'est dans les dépots.

Configuration

Il faut se munir d'une clef ssh et d'une clef gpg par machine.

Note : Le mot de passe de la clef gpg sera en clair dans les scripts d'automatisation s'il y en a un (d'où le pourquoi je souhaite vraiment plein de clefs de partout).

Donc par machine (la clef ssh c'est uniquement pour la connection au NAS, donc fait là ou je n'en avais pas déjà une à disposition) :

$ ssh-keygen -t ed25519
$ gpg --full-generate-key

Réponse aux petites questions basiques, et c'est tout⁵ pour les clefs ici.

J'ai déposé la clef publique ssh pour me connecter sans entrer de mot de passe au NAS :

client$ scp .ssh/maClef.pub monUserDeBackup@monNas:~/

puis :

nas$ mkdir -p .ssh
nas$ touch .ssh/authorized_keys
nas$ cat maClef.pub >> .ssh/authorized_keys
nas$ rm maClef.pub

et enfin pour vérifier que je me connecte bien (ici j'ai pas l'identité ssh par défaut, parce que je le vaut bien) :

client$ ssh -i .ssh/maClef monUserDeBackup@monNas

Comme je suis feignantinformaticien, j'ai modifié mon .ssh/config :

Host monNas
     Hostname monNas
     User monUserDeBackup
     IdentityFile ~/.ssh/maClef

Pour faire les bacups proprement dites, maintenant, j'ai pris les premiers scripts d'exemple proposés pour pouvoir faire une version full et une version incrémentale :

$ wget http://duplicity.nongnu.org/contrib/jwfull -O /tmp/full-backup.sh
$ wget http://duplicity.nongnu.org/contrib/jwincr -O /tmp/inc-backup.sh

La variable PASSPHRASE doit contenir le mot de passe associé à la clef gpg pour duplicity pour la machine courante (et vive les notes de quoi sert pourquoi).

Il faut modifier les lignes d'appel à duplicity pour inclure/exclure ce que l'on souhaite, créer les rapports que l'on souhaite, et après, "yapukà" tester les deux scripts, sur chaque machine.

Note : le script suppose que vous pouvez envoyer des mails, et je crois que c'est une vieille syntaxe, pour la commande mail. Enfin moi, je l'ai changée⁶.

Je les ai rangés une fois ok dans le .local/bin/ de l'utilisateur de chaque machine (il n'y en a qu'un utilisateur à backuper, et je ne veux rien
d'autre que ses données).

Automatisation

Maintenant que c'est manuel, il faut passer aux choses sérieuses pour ne plus y penser. Donc entre systemd, vu qu'on ma dit que je pouvais dire ok, systemd, pense à faire mes backups tous les jours.

Un petit lot de .config/systemd/user/full-backup.service,
.config/systemd/user/full-backup.timer,
.config/systemd/user/inc-backup.service et
.config/systemd/user/inc-backup.timer plus tard, et c'est
toto-matique partout⁷.

Et voilà !

C'était pas si dur, en fait.

Gestion des mots de passe

Il s'agit ici des mots de passe. Je voulais faire toujours avec la base commune, seul gpg est utilisé au final dans la configuration pour laquelle j'ai opté. Peut-être que j'aurais pu utiliser à nouveau mon NAS et ssh, mais pour quoi faire compliqué si git permet de faire le travail de synchro ?

C'est certes pas trop fait pour du binaire, et mieux vaut garder le projet privé par sécurité, mais ça ne me semble pas introduire de trou béant niveau sécurité. Cependant je ne suis pas un dieu dans ce domaine.

Installation

Il n'y a pas (encore) de paquet debian. Ou plutôt, il y en a un, qui s'appelle gopass, mais c'est pas la même chose :)

Donc, il faut faire un peu de choses à la main (y'a un .deb quand même, c'est pas si compliqué que ça) :

# apt-get install gnupg2 git rng-tools
$ git config --global gpg.program gpg2 # pas en root, hein !
$ wget https://github.com/gopasspw/gopass/releases/download/v1.12.7/gopass_1.12.7_linux_amd64.deb
# dpkg -i gopass_1.12.7_linux_amd64.deb

Etpicétout pour l'installation.

Configuration

J'ai un compte git sur gitlab, déjà configuré avec une clef pour y accéder (enfin, une par machine, quoi). Je ne crois pas que ça change quoi que ce soit de ne pas avoir un compte autant configuré. Mais bon, ça me fait une clef de plus dans le lot, de quoi finir par s'y perdre si on ne fait pas attention :)

Et hop, c'est parti pour une clef gpg par machine :

$ gpg --full-generate-key

Réponse aux petites questions basiques, et c'est presque tout pour gpg : j'ai aussi échangé les clefs publiques entre les machines.

Pour la création du projet git associé, je suis passé simplement par l'interface web, nouveau projet, et rien de particulier de plus.

Puis, sur une machine :

$ gopass setup --crypto gpg --storage gitfs # ici, avec la clef de cette machine
$ gopass recipients add 123456789 # ici, l'id de la clef GPG pour l'autre machine

Et sur l'autre machine, simplement :

$ gopass setup --crypto gpg --storage gitfs

Ajout, synchronisation

Pour de l'utilisation basique, il n'est pas nécessaire de connaître git, un ajout se fait simplement via :

$ gopass insert linuxfr.org/creds

par exemple pour ajouter le mot de passe associé à mon utilisateur linuxfr, ou bien :

$ gopass ls

pour lister les clefs, ou encore :

$ gopass show linuxfr.org/creds

pour afficher le secret associé à cette clef.

En général, la synchro se déclenche à l'ajout, et si je veux mettre à jour pour récupérer les nouveautés, un petit gopass sync fait l'affaire.

Petites touches finales

Pour la complétion avec zsh, je me suis contenté de suivre les instructions (ce n'est peut-être pas terrible d'aller dans /usr/share/zsh/, cependant) :

$ gopass completion zsh > ~/_gopass
$ sudo mv ~/_gopass /usr/share/zsh/vendor-completions/_gopass # mettre les bons droits, aussi
$ rm -i ${ZDOTDIR:-${HOME:?No ZDOTDIR or HOME}}/.zcompdump && compinit

Une petite vérification proposée me semble pertinente (Securing Your Editor), mais je n'ai rien eu à faire de particulier. Ça serait assez dommage de laisser un trou de sécurité comme ça, par oubli (lors de l'édition, le fichier temporaire est potentiellement enregistré en clair sur disque ! Un malheureux bug pourrait l'y laisser déchiffré, potentiellement
lisible…).

Il existe aussi une interface graphique, mais que je n'ai pas exploré au delà de l'installation.

Conclusion et reste à faire

Cependant, pour être vraiment complet, il y a encore des manques :

• vérifier régulièrement les backups, c'est mieux,
• externaliser le stockage physique (copie des backups full), c'est à faire,
• prévoir un mécanisme de gestion des clefs privées de backup, c'est à faire aussi. Des backups chiffrées sans possibilité de les ouvrir, c'est un peu bof
• je ne sais pas s'il ne vaudrait pas mieux un gitlab auto-hébergé quand-même pour les mots de passe

Peut-être pour une suite ?

Donc tu vois, 'nal, toi aussi, tu peux le faire, et c'était pas si long (pour moi) !

Alors plus d'excuse et merci d'avoir lu jusque là ;)

Pense à la tête de ton ami noob, quand tu lui racontera tout ça… Rien que cette idée devrait te motiver, non ?