Forum Linux.général Timeout sur la saisie du mot de passe Luks

Posté par  . Licence CC By‑SA.
Étiquettes :
0
7
jan.
2020

Bonjour,

J'ai un petit serveur qui tourne sur Proxmox.
Dedans, j'ai deux disques durs chiffrés via Luks qui sont ensuite utilisés par ZFS en mode miroir.
Ces deux disques ne sont pas requis pour faire fonctionner Proxmox et certains containers et/ou VM.

Quand le serveur redémarre, j'ai un prompt pour la saisie du mot de passe.
Cependant, si je ne suis pas chez moi, j'aimerais bien que le serveur se relance même sans ce pool zfs.
J'ai testé les paramètres timeout et x-systemd.device-timeout dans le fichier crypttab mais cela ne change pas grand chose.
cf. https://www.freedesktop.org/software/systemd/man/crypttab.html

Par ailleurs, si je saisie un mauvais mot de passe le serveur démarre bien sans les disques.

Auriez vous des idées ?

Merci.

  • # noauto pourrait faire ca

    Posté par  . Évalué à 6.

    noauto
    This device will not be added to cryptsetup.target. This means that it will not be automatically unlocked on boot, unless something else pulls it in. In particular, if the device is used for a mount point, it'll be unlocked automatically during boot, unless the mount point itself is also disabled with noauto.

    ca n'active pas le peripherique au boot, sauf si quelqu'un le demande spécifiquement.
    dans ton cas le ZFS s'il est en montage automatique

    suffirait alors que le ZFS ne démarres pas tout seul au boot,
    ton volume chiffré n'est alors pas demandé,
    et l'option noauto fera que le prompt n'apparaitra pas.

    à toi alors d'activer le ZFS après le boot, et donc demander les volumes chiffrés, et rentrer le pass.

  • # Dans le même veine (en mode schmilblik)

    Posté par  . Évalué à 1.

    Hello sifu,

    Dans le même veine que le mot de passe erroné, je propose un certificat bidon, tu indiques un certificat inexistant ou existant mais pas fonctionnel, si ça fait la même chose que pour le mot de passe, alors le boot continuera ?

    Sinon (sans doute la meilleur piste à creuser), il doit être possible de ne pas les déchiffrer automatiquement ?

    Idée 3 (3 pour le prix d'une) tu fais 2 fichier crypttab, un vide, un avec les bonnes informations et tu te fais un script/alias qui va remplacer le fichier vide et déchiffrer les disques à la demande (sans oublier de mettre une fonction dans systemd pour remplacer le fichier vide au besoin)

    Pour étayer, je proposes une explication :
    crypttab (celui qui sera lu par cryptsetup)
    crypttab-vide (le fichier vide)
    crypttab-OK (celui avec les informations concernant tes 2 disques)
    Pour déchiffrer, tu lances la commande :
    cp /etc/crypttab-OK /etc/crypttab && cryptsetup open /dev/sdx --type blabla

    Pour que les disques ne soient pas déchiffrés au démarrage, tu lances un cron, ou via systemd la commande :
    cp /etc/crypttab-vide /etc/crypttab

    Du coup au démarrage, il n'y a rien dans le fichier et le boot continues sans blocage

    Dis nous si tu trouves une solution intelligente ;-)

    Julien_c'est_bien (y'a pas que Seb)

  • # Full disk encryption et chiffrement de ZFS

    Posté par  . Évalué à 3.

    Ça ne t’aideras probablement pas à résoudre le soucis (quoi que, peut-être que tu voudras changé ta manière de faire), mais j’ai un fonctionnement un peu différent de toi : l’entièreté de mes disques sont chiffrés et j’utilise dropbear pour me connecter à distance et déchiffrer les volumes après un redémarrage du serveur.

    Le schéma est le suivant (j’ai pas accès aux machines actuellement donc c’est de tête) :

    /dev/sd[ab]1 (RAID1)
  → /dev/md0
    → /boot (ext4)
/dev/sd[ab]2 (RAID1)
  → /dev/md1 (LUKS)
    → /dev/mapper/md1 (LVM)
      → / (ext4)
      → /var/lib/vz (ext4) (principalement pour les iso et parfois pour des backups locaux)
      → Un thin pool pour les VMs

    Quand le serveur démarre, l’initramfs lance dropbear et attends que quelqu’un entre la clef de déchiffrement.

    Autre question/remarque, pourquoi ne pas utiliser le chiffrement intégré à ZoL ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.