tag:linuxfr.org,2005:/tags/cryptsetup/publicLinuxFr.org : les contenus étiquetés avec « cryptsetup »2022-08-01T10:29:12+02:00/favicon.pngtag:linuxfr.org,2005:Diary/403252022-07-12T21:58:11+02:002022-07-12T21:58:11+02:00bépo, cryptsetup et debianLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Salut </p>
<p>Un petit journal vite fait pour rapporter un truc qui m'a fait un peu peur.</p>
<h3 id="toc-description">Description</h3>
<p>J'ai récemment installé une débian 11 avec chiffrage du disque dur. Tout ce passe bien.</p>
<p>J'installe un agencement bépo et je n'y pense plus.</p>
<p>Je dois entrer le mot de passe du disque dur en azerty et celui de session en bépo.</p>
<p>Un matin, après une mise à jour noyau, <a href="https://packages.debian.org/bullseye/cryptsetup"><code>cryptsetup</code></a> ne veux rien savoir, quand j'entre mon mot de passe, il ne me répond que <code>cryptsetup: Bad password or options?</code>. Dur.</p>
<p>J'arrive à booter sur le vieux noyau. Je demande à internet qui me dit que ça doit venir entre autre de l'agencement du clavier.</p>
<p>Effectivement, lors de la mise à jour du noyau, et surtout lors de la génération du <code>initrd</code>, la disposition était le bépo.</p>
<p>Problème : quelle que soit la façon dont j'entre le mot de passe, <code>cryptsetup</code> ne veut rien savoir.</p>
<h3 id="toc-solution-rapide--restaurer-la-disposition-par-défaut-dans-initrd">Solution rapide : restaurer la disposition par défaut dans initrd.</h3>
<p>Bon comme je veux quand même utiliser le nouveau noyau, je vais essayer de réparer le initrd.</p>
<h4 id="toc-1-desarchiver-les-initrd">1. Desarchiver les initrd.</h4>
<p>Dans un premier temps, on desarchive les deux initrd, l'un pour le réparer, l'autre pour récupérer un fichier à mettre dans le premier</p>
<pre><code class="bash">mkdir /tmp/old /tmp/new
<span class="nb">cd</span> /tmp/old
zcat /boot/initrd.img-5.10.0-15-amd64 <span class="p">|</span> cpio -i
<span class="nb">cd</span> /tmp/new
zcat /boot/initrd.img-5.10.0-16-amd64 <span class="p">|</span> cpio -i</code></pre>
<h4 id="toc-2-répararer-les-fichiers">2. Répararer les fichiers</h4>
<p>En comparant les arborescences, on trouve deux fichiers qui pourraient expliquer le problème: <code>/etc/console-setup/cached_UTF-8_del.kmap</code> et <code>/etc/default/keyboard</code>.</p>
<p>Il suffit de prendre les vieux et les mettre à la places des neufs:</p>
<pre><code class="bash"><span class="c1">## comparer les initrd facilement:</span>
<span class="c1">#meld /tmp/old /tmp/new</span>
cp /tmp/old/etc/console-setup/cached_UTF-8_del.kmap /tmp/new/etc/console-setup/cached_UTF-8_del.kmap
cp /tmp/old/etc/default/keyboard /tmp/new/etc/default/keyboard</code></pre>
<h4 id="toc-3-régéner-linitrd">3. Régéner l'initrd</h4>
<p>Il ne reste plus qu'à archiver l'initrd et le mettre au bon endroit. </p>
<pre><code class="bash"><span class="nb">cd</span> /tmp/new
find <span class="p">|</span> cpio -o <span class="p">|</span> gzip --best > /tmp/initrd.img-5.10.0-16-amd64
sudo cp /tmp/initrd.img-5.10.0-16-amd64 /boot/initrd.img-5.10.0-16-amd64</code></pre>
<h3 id="toc-solution-lente--corriger-vraiment-le-problème">Solution lente : corriger vraiment le problème</h3>
<p>Pour faire les choses bien, j'aurai plusieurs choix :</p>
<ul>
<li>Apprendre à me servir de <code>mkinitramfs</code> pour choisir un agencement qui fonctionne</li>
<li>Comprendre pourquoi l'agencement bépo ne fonctionne pas avec <code>cryptsetup</code> et le réparer</li>
</ul>
<p>Mais il est tard, ça sera pour une prochaine fois</p>
<p>Une nimage pour faire de beaux rèves : <br>
<img src="//img.linuxfr.org/img/68747470733a2f2f75706c6f61642e77696b696d656469612e6f72672f77696b6970656469612f636f6d6d6f6e732f7468756d622f362f36652f4d61696e5f696d6167655f646565705f6669656c645f736d616373303732332e706e672f34373070782d4d61696e5f696d6167655f646565705f6669656c645f736d616373303732332e706e67/470px-Main_image_deep_field_smacs0723.png" alt="nimage" title="Source : https://upload.wikimedia.org/wikipedia/commons/thumb/6/6e/Main_image_deep_field_smacs0723.png/470px-Main_image_deep_field_smacs0723.png"></p>
<div><a href="https://linuxfr.org/users/purplepsycho/journaux/bepo-cryptsetup-et-debian.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/128288/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/purplepsycho/journaux/bepo-cryptsetup-et-debian#comments">ouvrir dans le navigateur</a>
</p>
purplepsychohttps://linuxfr.org/nodes/128288/comments.atomtag:linuxfr.org,2005:Diary/376442017-12-14T09:46:06+01:002017-12-14T09:46:06+01:00Le LUKS, version 2Licence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Bon alors, les crypto-nerds, vous êtes plus flemmard que moi ?</p>
<h4 id="cryptsetup-2-est-sorti"><a href="http://www.saout.de/pipermail/dm-crypt/2017-December/005771.html">Cryptsetup 2 est sorti</a></h4>
<p>Euh, bon, je met vite fait ce que j'ai vu :</p>
<ul>
<li>Nouveau format LUKS2, que l'on peut (la plupart du temps) mettre à jour depuis LUKS1</li>
<li>LUKS1 sera supporté pour toujours</li>
<li>LUKS2 sait faire de l'intégrité. Attention, c'est encore expérimental</li>
<li>Support de chiffrement de mot passe plus résistant à la force brute (genre coûteux en mémoire) avec PBKDF et Argon2</li>
<li>Options de montage persistantes dans les en-têtes. Comme tune2fs. Je crois que ça va être bien.</li>
<li>Il est possible (si j'ai bien compris), de dire à cryptsetup de stocker un jeton pour dire de trouver le mot de passe tout seul dans un gestionnaire de clés. C'est pas clair pour moi non plus, parce que j'ai lu en diagonale.</li>
</ul><h5 id="bonus">Bonus</h5>
<ul>
<li>Y a du JSON dedans. C'est très hype (mais surtout extensible)</li>
</ul><p>Voilà, c'est très résumé. Parce que je suis tellement flemmard que je dois le répéter deux fois.</p><div><a href="https://linuxfr.org/users/glandos/journaux/le-luks-version-2.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/113306/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/glandos/journaux/le-luks-version-2#comments">ouvrir dans le navigateur</a>
</p>
Glandoshttps://linuxfr.org/nodes/113306/comments.atomtag:linuxfr.org,2005:Post/370992016-07-27T14:54:10+02:002016-07-27T14:54:10+02:00Volume chiffré<p>Bonjour,</p>
<p>Je voudrais stocker quelques informations dans mon $HOME et que ces informations restent privées. Or quiconque est en mesure de se connecter en <em>root</em> peut bien évidemment accéder à mon $HOME. Je me suis donc dit que je pouvais créer un volume chiffré (j’ai en effet moi aussi un accès <em>root</em> sur cette machine). Je ne l’avais jamais fait, c’est vraiment très simple.</p>
<p>Je vous soumets donc la méthode à laquelle je suis arrivé, pour avoir votre avis et éventuellement pouvoir y apporter des améliorations.</p>
<p>Tout d’abord une chose dont j’ai bien conscience c’est qu’une fois le volume chiffré ouvert, <em>root</em> pourra y accéder, donc ce n’est pas terrible mais si je referme systématiquement le volume ça reste quand même une protection contre le fouineur de base.</p>
<pre><code class="bash"><span class="c">#!/usr/bin/env bash</span>
<span class="k">case</span> <span class="s2">"$1"</span> in
<span class="s2">"open"</span><span class="o">)</span>
sudo losetup /dev/loop5 ~/stash.img
sudo cryptsetup luksOpen /dev/loop5 stash
sudo mount /dev/mapper/stash ~/stash
<span class="p">;;</span>
<span class="s2">"close"</span><span class="o">)</span>
sudo umount ~/stash
sudo cryptsetup luksClose /dev/mapper/stash
sudo losetup -d /dev/loop5
<span class="p">;;</span>
<span class="s2">"pass"</span><span class="o">)</span>
<span class="nv">$0</span> open<span class="p">;</span>
<span class="nv">$EDITOR</span> ~/stash/pass<span class="p">;</span>
<span class="nv">$0</span> close<span class="p">;</span>
<span class="p">;;</span>
*<span class="o">)</span>
<span class="nb">echo</span> <span class="s2">"Usage: secsta [open|close|pass]"</span>
<span class="nb">exit </span>1
<span class="p">;;</span>
<span class="k">esac</span></code></pre>
<p>Je voudrais notamment connaître votre avis sur la troisième option (pass) qui ouvre le volume chiffré, lance un éditeur sur l’un des fichiers de ce volume, puis referme le volume chiffré lorsque l’on quitte l’éditeur.</p>
<p>Je compte aussi appeler ce script avec l’option "close" dans <em>~/.bash_logout</em> car je n’ai pas de tête.</p>
<p>Avec cette méthode, quelle est la probabilité que <em>root</em> puisse accéder au fichier <em>~/stash/pass</em> ? Est-ce que root peut accéder à ce fichier lorsqu’il est ouvert dans l’éditeur (je dirais oui) ?</p><div><a href="https://linuxfr.org/forums/linux-general/posts/volume-chiffre.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/109653/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-general/posts/volume-chiffre#comments">ouvrir dans le navigateur</a>
</p>
Marotte ⛧https://linuxfr.org/nodes/109653/comments.atomtag:linuxfr.org,2005:Post/366902016-04-04T09:07:27+02:002016-04-04T09:07:27+02:00Cryptsetup: help !!!<p>Bonjour,</p>
<p>Je souhaiterais installer cryptsetup sur une cible ARM avec un linux sans biensur utiliser apt-get ou autre programme d'installation.<br>
Pour ce faire J'ai déjà cross compilé sur mon hôte avec l'option arm-linux-gnueabihf, libgpg-error, libgcrypt, lvm2 et pour finir cryptsetup. La compile s'est bien passée, j'ai donc cryptsetup disponible sur mon hôte.</p>
<p>Maintenant je me trouve bloqué pour passer a l'étape suivante qui consiste a exécuter cryptsetup depuis ma cible.<br>
Auriez vous une idée ? Quelles sont les autres étapes nécessaires ?</p>
<p>Merci d'avance</p><div><a href="https://linuxfr.org/forums/linux-embarque/posts/cryptsetup-help.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/108628/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-embarque/posts/cryptsetup-help#comments">ouvrir dans le navigateur</a>
</p>
Vanouhttps://linuxfr.org/nodes/108628/comments.atom