Différences

Ci-dessous, les différences entre deux révisions de la page.

--- tutoriel:sauvegardes_nomades_securisees [Le 06/03/2024, 09:05]
bcag2 [Voir aussi] suppr [wiki] les liens inter-wiki sont là pour ça
+++ tutoriel:sauvegardes_nomades_securisees [Le 19/02/2025, 18:10] (Version actuelle)
bcag2 [Udev : Déclencher la sauvegarde à la connexion du disque usb] suppr notes qui n'apporte rien (pas de version ni contexte !)!
@@ Ligne 30: / Ligne 30: @@
   * Apprenez à manipulez vos partitions chiffrées vous mêmes à la main. Vous voulez être compétents pour être en mesure de les utiliser quand vous aurez besoin de vos backups et que la situation vous échappera un peu…
   * Je réalise la plupart des opérations suivantes avec les outils graphiques de KDE. Je ne suis pas en mesure de donner les lignes de commande de façon suffisamment fiable pour une documentation publique. Suivez les étapes et faites attention à ce que vous faites.
-  * Toutes les commandes (ou presque) de ce tutoriel sont à passer en ''%%root%%'' (en utilisant ''%%sudo%%'') [Utiliser : ''%%sudo !!%%'' quand vous voulez passer ''%%en root%%'' la dernière commande que vous avez tenté en simple utilisateur].\\
+  * Toutes les commandes (ou presque) de ce tutoriel sont à passer en ''%%root%%'' (en utilisant ''%%sudo%%'')
+ <note tip>Utiliser : ''%%sudo !!%%'' quand vous voulez passer ''%%en root%%'' la dernière commande que vous avez tenté en simple utilisateur.</note>\\
   * Nous utilisons des scripts qui seront appelés en tant que root, mais que j’ai édité (plusieurs fois en mode essai-erreur) en tant qu’utilisateur. Il m’a fallu faire quelques ajustements au niveau des droits pour faire tout cela (commandes chown et chmod en sudo). [Par exemple, mettre “mon utilisateur” dans le groupe “root” et utiliser des [[:permissions|droits]] de type “root.root 760” pour que root puisse exécuter les scripts, moi pouvoir les éditer, et rien pour les autres] **Si vous n’êtes pas à l’aise avec ces manipulations, persévérez dans l’apprentissage de ces notions avant de configurer vos chiffrements ;-)**
-  * afin de voir les commandes qui passent quand on lance un script en console dans les phases de test : mettre ''%%set -x%%'' en début de script (et retirer ensuite)
+<note tip> afin de voir les commandes qui passent quand on lance un script en console dans les phases de test : mettre ''%%set -x%%'' en début de script (et retirer ensuite)</note>
+<note tip>On peut aussi loguer des informations utiles en ajoutant quelques éléments dans les scripts :
+- Ajouter une ligne `echo "$(date '+%Y-%m-%d %H:%M:%S') étape d'execution" >> /var/log/cryptshot.log`
+- Ajouter `| tee -a /var/log/cryptshot.log` à la suite d'un message du script  `echo 'message.' | tee -a /var/log/cryptshot.log`
+</note>
 ==== Quelques points de repères pour comprendre le système : ====
@@ Ligne 89: / Ligne 99: @@
 === Montage et démontages des volumes chiffés ===
-Vérifiez que vous êtes vraiment capables de manipuler vos partitions chiffrées en dehors des scripts …
+<note important>Vérifiez que vous êtes vraiment capables de manipuler vos partitions chiffrées en dehors des scripts …</note>
   * Ouvrir la partition chiffrée, le mot de passe sera demandé :
@@ Ligne 100: / Ligne 110: @@
 <code bash>
 cryptsetup -v luksOpen --key-file <chemin/Keyfile> /dev/<target device> monVolume
+</code>
+  * Vérifier un mot de passe et son slot, sans ouvrir la partition :
+<code bash>
+cryptsetup -v luksOpen --test-passphrase /dev/<target device>
 </code>
   * Montage du mapper
@@ Ligne 124: / Ligne 140: @@
 Pour approfondissements, voir :
-Nous aurons besoin d’au moins deux clés pour ouvrir le conteneur :
+<note important>Nous aurons besoin d’au moins deux clés pour ouvrir le conteneur :</note>
   - Un “keyfile” (qui peut être n’importe quel fichier) dans l’ordinateur pour automatiser la sauvegarde. Cette clé qui ne sera pas utilisable à qui disposerait du disque seulement : le voleur ou vous après la perte de l’ordinateur.
@@ Ligne 149: / Ligne 165: @@
 </code>
 === Sauvegarder l’entête du conteneur ===
+<note important>
-Cet entête intégral est indispensable à l’ouverture du conteneur. On peut l’altérer volontairement pour rendre le conteneur illisible à qui que ce soit, il peut aussi y avoir un accident ! Attention, l’entête contient tous les slots de mots de passe et keyfiles. Le restaurer remettra donc ces slots à l’état du moment de la sauvegarde, réactivant d’anciens mots de passe éliminés. Cela peut être une bréche de sécurité si la sauvegarde de l’entête est (a été) accessible à un ancien collaborateur .
+Cet entête intégral est indispensable à l’ouverture du conteneur.</note> On peut l’altérer volontairement pour rendre le conteneur illisible à qui que ce soit, il peut aussi y avoir un accident ! Attention, l’entête contient tous les slots de mots de passe et keyfiles. Le restaurer remettra donc ces slots à l’état du moment de la sauvegarde, réactivant d’anciens mots de passe éliminés. Cela peut être une bréche de sécurité si la sauvegarde de l’entête est (a été) accessible à un ancien collaborateur .
 luksHeaderBackup /dev/<html><target device></html> –header-backup-file <html><file></html>
@@ Ligne 244: / Ligne 260: @@
 Pour répéter les tests il faudra probablement enlever (ou remplacer par ''%%000%%'') les fichiers ''%%daily%%'' du répertoire précédent.
-==== Forcer une sauvegarde ====
+==== Forcer une sauvegarde par un nouveau script ====
 Pour forcer la sauvegarde quotidienne, même si elle a déjà été faite plus tôt dans la journée … Créer (encore) un script : ''%%/usr/local/bin/force-cryptshop.sh%%'' et le remplir avec :
@@ Ligne 259: / Ligne 275: @@
 </code>
 On pourra l’appeler en ligne de commande, en phase de tests, et pour sauvegarder les derniers travaux de la journée juste avant de quitter le lieu correspondant.
 ==== Udev : Déclencher la sauvegarde à la connexion du disque usb ====
@@ Ligne 267: / Ligne 284: @@
   * le peupler avec\\
 ''%%ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", RUN+="/etc/cron.hourly/cryptshot-execute"%%''
-  * rechargez les règles udev en utilisant la commande suivante Ou redémarrer) :<code>
+  * Redémarrer ou recharger les règles udev, puis "déclencher" (la redétection?) en utilisant la commande suivante :
-sudo udevadm control --reload-rules
+ <code>
+sudo udevadm control --reload-rules && sudo udevadm trigger
 </code>
   * Tester en connectant un des disques de sauvegarde
-===== Problèmes connus =====
+Le fonctionnement peut être capricieux quand le disque est connecté au travers d'un hub thunderbolt. Connecter alors le disque directement sur un port USB de l'ordinateur.
-Faire et automatiser des sauvegardes, c’est bien ; il faut aussi pouvoir les utiliser. Lorsque le disque USB est connecté, il apparait comme pouvant être moté dans l’espace utilisateur. Il faudra saisir le mot de passe pour l’ouvrir. Tout cela est bien, et nous permettra de consulter nos sauvegardes de n’importe quelle machine (non testé sous Windows ni MacOS); Sauf que …\\
-Cela fout le bordel sur la machine qui fait les sauvegardes. - Lorsque l’on ouvre le volume en tant qu’utilisateur (typiquement dans /media/user/monvolume) le script ''%%cryptshot%%'' s’arrête en erreur. Le développeur me dit que ce serait trop insécure de permettre simultanément les accès utilisateur et l’ouverture pour une sauvegarde en cours, elle attendra le prochain ''%%hourly%%''.\\
-- Lorsque l’on “détache” le disque USB, il n’apparait plus comme détecté par le system (les fichiers correspondants sous /dev/disk/*/… ne sont plus présents), alors le script ne peut plus tourner les sauvegardes non plus. - Une solution est de déconnecter/reconnecter le disque USB. A défaut d’y penser, on pourrait se retrouver sans sauvegardes pendant quelques jour… - Une autre solution que j’ai trouvé est de faire un (autre) script /usr/local/bin/Back-domicile-mount-sh avec :
+==== Lancer la sauvegarde à la connexion et la déconnexion de l'utilisateur ====
+L'idée : quand on arrive ou repart d'un lieu de travail, on veut que les sauvegardes soient mises à jour.
+Le moyen : placer des scripts adéquat à la connexion ou la déconnexion. Je l'ai fait dans l'interface de configuration de KDE, trouvez le moyen pour votre situation.
+Une difficulté : ces scripts sont lancés en tant qu'utilisateur, les sauvegardes doivent être lancées en root.
+se permettre de lancer sertains scripts en tant que root, sans mot de passe (puisque lancés automatiquement) :
 <code>
-#!/bin/bash
+sudo visudo  /etc/sudoers.d/mecryptshot
-mkdir /mnt/Monvolume
-cryptsetup luksOpen --key-file /chemin/de/la/cle.whatever /dev/disk/by-partlabel/Monvolume crypt-Monvolume
+me ALL=(ALL) NOPASSWD: /usr/local/bin/mecryptshop-force.sh,/usr/local/bin/mecryptshop-lance>
-mount --options noatime /dev/mapper/crypt-Monvolume /mnt/Monvolume
-read -p " $volume est monté, visiter /mnt puis appuyez sur Enter pour tout refermer"
-umount /mnt/Monvolume
-rmdir /mnt/monvolume
-cryptsetup luksClose crypt-Monvolume
 </code>
-Toujours lancer en root, par sudo. Cette ouverture et se montage ne “détache” pas le disque, et le script reste fonctionnel.
+```
+Créer les scripts correspondants :
-===== Conclusion =====
+Éditer : /usr/local/bin/mecryptshop-force.sh
+<code>
+#!/bin/bash
+sudo echo '000' > /usr/local/etc/cryptshot/lastrun/xadom.daily
+sudo echo '000' > /usr/local/etc/cryptshot/lastrun/alta.daily
-Il est prudent, dès lors qu'on utilise un ordinateur portable, de gérer ses sauvegardes, à plusieurs endroits et de façon chiffrée.
+sudo /usr/local/bin/cryptshot-execute
-Merci aux auteurs et contributeurs [[:rsnapshot]], des scripts //cryptshot// et //backitup// [[https://github.com/pigmonkey|pigmonkey]] pour leur patience et leur soutien. Les autres scripts proposés ici ont largement été inspirés par [[https://github.com/pigmonkey/cryptshot/issues/8|ces échanges]].
+exec >> "/var/log/cryptshot.log"
+echo "C'était mecryptshot-force.sh" /t
+</code>
-==== Piste pour gérer le problème ci dessus ====
-Proposée par l’auteur du script dans les “issues” [[https://github.com/pigmonkey/cryptshot/issues/8|Continue the script when the volume is already luksOpened ? · Issue #8 · pigmonkey/cryptshot · GitHub]] - non testé
+Éditer : /usr/local/bin/mecryptshop-lance.sh
+<code>
+#!/bin/bash
+sudo /usr/local/bin/cryptshot-execute
+exec >> "/var/log/cryptshot.log"
+echo "C'était mecryptshot-lance.sh" /t
+</code>
+Ces scripts déclenchent les opérations comme confugurées dans les étapes précédentes.
+==== Consulter les sauvegardes ====
+Là ou je suis, avec KDE, le montage par les outils graphique pose des problèmes. Le démontage quand on ferme le volume n'est pas complet, et il y a une erreur ensuite quand le script essaye de luksopen le volume.
+j'utilise encore des scripts ...
+Sudo est souhaitable pour contrôler l'accès aux sauvegardes, sinon ajuster visudo en conséquence
+On déchiffre le volume, et on le regarde avec mc (c'est mon choix).
+Pour fouiller les sauvegardes plus facilement, tant que mc est ouvert dans la console, utiliser /mnt/<target device> comme chemim dans vos applications graphiques courantes.
+A la fermeture de mc, le volume sera démonté, et les sauvegardes suivantes seront fonctionnelles.
+/usr/local/bin/memount-mydomicile-sh
 <code>
+#!/bin/bash
+ mkdir /mnt/<target device>
+ cryptsetup luksOpen --key-file <chemin/Keyfile> /dev/<target device>  crypt-<target device>
+ mount --options noatime /dev/mapper/crypt-<target device> /mnt<target device>
+ mc /mnt/<target device>
+ umount  /mnt/<target device>
+# rmdir  /mnt/<target device>
+ cryptsetup luksClose crypt-<target device>
+</code>
+===== Problème connus =====
+J'ai eu quelques difficultés à assurer le démontage du volume crypté quand j'utilisais les outils graphiques de KDE pour le consulter. Le chapitre précédent fonctionne adéquatement, mais si vous rencontrez ce genre de problème, le développeur de cryptshot m'a proposé une autres apprche de cette nature. voir [[https://github.com/pigmonkey/cryptshot/issues/8|Continue the script when the volume is already luksOpened ? · Issue #8 · pigmonkey/cryptshot · GitHub]]
+<code>
 if [ -d /mnt/backupdrive ]; then
     rsnapshot -c /path/to/rsnapshot.conf daily
@@ Ligne 308: / Ligne 368: @@
     cryptshot.sh -c /path/to/cryptshot.conf -i daily
 fi
 </code>
-==== Incron, comme alternative à Udev ? ====
+A toutes fiins utiles - non testé
-non testé
-[[https://doc.ubuntu-fr.org/incron|incron [Wiki ubuntu-fr]]]
-[[https://www.it-connect.fr/incron-executer-des-actions-selon-des-evenements/|Incron : exécuter des actions selon des événements | Commandes et Système | IT-Connect]]
+===== Conclusion =====
+Il est prudent, dès lors qu'on utilise un ordinateur portable, de gérer ses sauvegardes, à plusieurs endroits et de façon chiffrée.
+Merci aux auteurs et contributeurs [[:rsnapshot]], des scripts //cryptshot// et //backitup// [[https://github.com/pigmonkey|pigmonkey]] pour leur patience et leur soutien. Les autres scripts proposés ici ont largement été inspirés par [[https://github.com/pigmonkey/cryptshot/issues/8|ces échanges]].
+Cet aricle reste "en cours de rédaction" en attendant que quelqu'un témoigne de l'avoir utilisé sans y avoir trouvé d'erreur. Si vous y parvenez, pour pourriez enlever ou demande d'enlever l'alerte en haut d'article.
 ===== Voir aussi =====
@@ Ligne 344: / Ligne 406: @@
 [[:tutoriel/sauvegarder_home|tutoriel sauvegarder son “home”]]
+** Incron, comme alternative à Udev (non testé) **\\
+ [[:incron|Incron]]
+[[https://www.it-connect.fr/incron-executer-des-actions-selon-des-evenements/|Incron : exécuter des actions selon des événements | Commandes et Système | IT-Connect]]
 ----