Informatique – Page 19

pass comme gestionnaire de mot de passe

Cela fait maintenant plusieurs années que j’utilise un gestionnaire de mot de passe pour retenir à ma place les informations d’accès aux différents services que j’utilise. J’avais jusqu’à présent choisi d’utiliser Keepass, en particulier pour ces fonctions de synchroniser via WebDAV et l’existence de ses nombreuses variantes qui permettent une utilisation sur GNU/Linux, Windows, Mac et Android sans trop de difficultés. Très récemment, j’ai décidé de changer de gestionnaire et de tester pass.

Quelques mots sur pass. Le programme de base prend la forme d’une simple ligne de commande. Chaque entrée consiste en un fichier dont la première ligne contient le mot de passe. On peut ensuite stocker diverses informations sur les lignes suivantes, comme url, username, clés d’API, etc. Tous les fichiers sont chiffrés par clé gpg. Lorsqu’on accède à l’un des fichiers de mot de passe, seul ce fichier sera déchiffré et non l’ensemble de la base comme c’est en général le cas avec les autres gestionnaires. La synchronisation est assurée par git, ce qui permet de bénéficier de l’historique du dépôt qui constituera notre base de référence de mot de passe.

Continuer la lecture

Carnet 4 – Migration

J’ai migré hier soir unicoda.com vers un nouveau VPS, toujours chez OVH, dans leur centre de données de Strasbourg. J’ai réalisé l’installation complète à partir d’un script ansible qui réinstalle le site à partir de la sauvegarde quotidienne stockée dans le cloud et reconfigure automatiquement le processus de sauvegarde.

L’ancien serveur va continuer de fonctionner encore quelques jours, le temps de s’assurer que la propagation des DNS aura eu lieu pour la plupart des lecteurs. La sauvegarde est désormais désactivée sur ce serveur.

Au passage, j’en ai profité pour récupérer une sauvegarde locale du site sur mon poste. On est jamais trop prudent. Il restera à vérifier dans quelques semaines que le renouvellement du certificat aura été effectué correctement de manière automatique. Il n’y a priori pas de raison que cela ne fonctionne pas, mais étant donné que j’utilise désormais le client acme.sh à la place de certbot pour demander un certificat wildcard, des vérifications s’imposent.

Au passage, un petit tour du côté de la page SSL Server Test du SSL Labs, me gratifie d’un joli A+, qui témoigne du chemin parcouru depuis la première mise en place du HTTPS sur ces pages (B- ou C au début).

Au moment où j’écris ces lignes, c’est-à-dire quelques heures après l’opération de migration, je n’ai détecté aucun problème de configuration ou de fonctionnement. Toutefois, lecteurs attentifs, n’hésitez pas à me signaler tous dysfonctionnements que vous auriez remarqué.

Création d’un accès à l’API OVH

Afin de pouvoir générer un certificat wildcard via Let’s Encrypt pour un domaine géré par OVH, il est nécessaire de créer un accès à l’API OVH sur la page de création de token.

Les autorisations à accorder sont les suivantes:

GET /domain/zone/*
PUT /domain/zone/*
POST /domain/zone/*
DELETE /domain/zone/*

Une fois l’ensemble des informations renseignées et validées, la page nous génère les clés d’API que l’on prendra soin d’enregistrer dans son gestionnaire de mot de passe favori.

S’il doit être possible de lister les accès accordés et de les gérer quelque part dans les interfaces d’administration OVH, je n’ai pour l’instant pas trouvé une telle page (mais je n’ai pas non plus pris le temps d’aller à sa recherche).

Restauration d’un dossier à partir de la sauvegarde avec duplicity

Pour une raison obscure, ma dernière tentative de mise à jour de Nextcloud a échoué et laissé le contenu du dossier dans un état instable. J’ai donc récupéré la dernière version stable depuis la sauvegarde de la veille.

sudo pip install --upgrade b2
sudo duplicity restore --force --file-to-restore path/to/nextcloud -t now b2://[applicationKeyId]:[application key]@[B2 bucket name] /path/to/nextcloud

gpg et pinentry

J’ai réalisé une modification du paramètre pinentry-program du côté de mon fichier de configuration de l’agent gpg à savoir ~/.gnupg/pgp-agent.conf :

# Ancienne valeur :
# pinentry-program /usr/bin/pinentry-curses
# Nouvelle valeur :
pinentry-program /usr/bin/pinentry

Ceci a pour effet d’utiliser le pinentry par défaut, soit pinentry-gtk-2 dans mon cas. J’effectue ce changement, car pinentry-curses n’arrive pas à s’afficher correctement si le déclencheur n’est pas une application lancée dans un terminal. J’ai notamment rencontré des problèmes au démarrage de Webstorm, lorsque celui-ci lance des commandes git en arrière plan pour rechercher d’éventuelles nouveautés. Si un terminal était déjà ouvert, l’interface curses y apparaissait, mais impossible d’y saisir correctement le PIN. Problème similaire en testant passmenu: pas d’affichage de l’interface.

Une fois la modification de configuration effectuée, on redémarre notre agent :

gpg-connect-agent reloadagent /bye