Comment déverrouiller à distance un serveur loué chiffré avec LUKS ?

Pourquoi le déverrouillage à distance compte-t-il sur un serveur loué ?

Parce qu'un disque chiffré attend sa clé à chaque démarrage, et personne n'est devant l'écran. Il n'y a pas d'accès IPMI ou KVM-over-IP pour les clients ; les redémarrages et réinstallations que vous demandez dans le tableau de bord sont effectués par l'équipe.

Planifiez donc le déverrouillage avant de chiffrer. Sur un hold, le système d'exploitation vit sur son propre SSD et les disques de données arrivent vierges. Cette séparation rend la première méthode simple : gardez le système en clair, chiffrez les disques qui contiennent vos données.

Chiffrez les disques qui contiennent vos données ; gardez le chemin de démarrage assez simple pour être réparable via SSH.

Comment chiffrer les disques de données et les déverrouiller après un redémarrage ?

Formatez chaque disque de données en LUKS2, ouvrez-le, et construisez le volume agrégé sur les périphériques ouverts. La phrase secrète ne touche jamais le disque du serveur. Après un redémarrage, le système démarre, vous vous connectez via SSH et vous ouvrez à nouveau les disques. Le choix du volume agrégé par-dessus est traité dans ZFS ou RAID matériel.

Les services qui utilisent le pool attendent que vous le fassiez. Une supervision de disponibilité externe, ou un script qui alerte quand le pool est absent, vous signale qu'un redémarrage a eu lieu.

apt install cryptsetup
# ZFS tools: zfsutils-linux and zfs-dkms from Debian contrib; built into Proxmox

# once per data drive: this erases it and asks for a passphrase
cryptsetup luksFormat --type luks2 /dev/disk/by-id/ata-MODEL_SERIAL01
cryptsetup open /dev/disk/by-id/ata-MODEL_SERIAL01 data01
# ...repeat for data02, data03, data04

zpool create -o ashift=12 tank raidz2 \
  /dev/mapper/data01 /dev/mapper/data02 /dev/mapper/data03 /dev/mapper/data04

# after every reboot: log in, open each drive, import the pool
cryptsetup open /dev/disk/by-id/ata-MODEL_SERIAL01 data01
# ...repeat for each drive
zpool import tank

Le chiffrement natif de ZFS peut-il remplacer LUKS ?

Oui, par dataset. Créez le dataset avec encryption=on et une phrase secrète, puis lancez zfs load-key et zfs mount après chaque redémarrage. Aucun travail sur l'initramfs n'est nécessaire.

Il dissimule toutefois moins de choses. Le manuel OpenZFS indique que ZFS ne chiffre pas les métadonnées de structure du pool : les noms de datasets et de snapshots, les propriétés et la taille des fichiers restent lisibles. LUKS chiffre le disque entier, métadonnées comprises. Les deux sont couverts par la même promesse : Vous pouvez chiffrer chaque disque de données avec LUKS ou le chiffrement natif ZFS ; les clés restent chez vous et personne dans l'équipe ne vous les demande.

Comment déverrouiller automatiquement les disques avec Clevis et Tang ?

Faites tourner un serveur Tang sur une machine que vous contrôlez ailleurs, et liez chaque disque à lui. Clevis ajoute un nouveau slot de clé à LUKS et stocke la clé chiffrée dans l'en-tête LUKS. Au démarrage, il demande à Tang d'aider à récupérer la clé ; votre phrase secrète continue de fonctionner comme avant.

Le manuel de Clevis indique que le déverrouillage en début de démarrage ne couvre que le volume racine. Les disques de données utilisent le déverrouilleur de fin de démarrage, qui lit /etc/crypttab. Sur Debian, le paquet clevis-systemd y déverrouille les périphériques marqués _netdev.

Les disques ne s'ouvrent que tant que le serveur de stockage peut joindre votre serveur Tang. N'autorisez que l'adresse IP du serveur de stockage à travers le pare-feu de Tang. Les disques qui quittent ce réseau restent verrouillés.

# on your Tang machine, not on the storage server
apt install tang
systemctl enable tangd.socket --now

# on the storage server
apt install clevis clevis-luks clevis-systemd
clevis luks bind -d /dev/disk/by-id/ata-MODEL_SERIAL01 tang '{"url": "http://TANG_ADDRESS"}'
# ...repeat for each data drive

# /etc/crypttab, one line per drive:
# data01  /dev/disk/by-id/ata-MODEL_SERIAL01  none  luks,_netdev

systemctl enable clevis-luks-askpass.path

# check the binding, or unlock by hand
clevis luks list -d /dev/disk/by-id/ata-MODEL_SERIAL01
clevis luks unlock -d /dev/disk/by-id/ata-MODEL_SERIAL01

Comment déverrouiller une racine chiffrée avec dropbear-initramfs ?

Placez un petit serveur SSH, dropbear, dans l'initramfs. Il démarre avant le système de fichiers racine, vous vous connectez avec votre clé et cryptroot-unlock demande la phrase secrète. Le guide cryptsetup de Debian décrit cette procédure pour les systèmes headless.

Le README de Debian fixe les règles. Les clés vont dans /etc/dropbear/initramfs/authorized_keys, et les connexions par mot de passe sont désactivées. Les options vont dans /etc/dropbear/initramfs/dropbear.conf. Le pilote réseau doit être dans /etc/initramfs-tools/modules, et une adresse statique se définit avec le paramètre ip= du noyau. Les mêmes chemins s'appliquent sur Debian 12, Debian 13 et Ubuntu 24.04.

L'initramfs utilise ses propres clés d'hôte, donc votre client SSH vous avertit d'un changement de clé. Gardez un fichier known_hosts à part pour lui, comme le suggère le README.

apt install dropbear-initramfs

# your public key, limited to the unlock command
echo 'no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/bin/cryptroot-unlock" ssh-ed25519 AAAA... you@laptop' \
  > /etc/dropbear/initramfs/authorized_keys

# listen on another port than the main SSH server
echo 'DROPBEAR_OPTIONS="-p 2222"' >> /etc/dropbear/initramfs/dropbear.conf

# static address in the initramfs: client::gateway:netmask::interface:off
# add to GRUB_CMDLINE_LINUX in /etc/default/grub, for example:
# ip=203.0.113.10::203.0.113.1:255.255.255.0::eno1:off
update-grub
update-initramfs -u -k all

# from your computer, at each boot
ssh -p 2222 -o UserKnownHostsFile=~/.ssh/known_hosts.initramfs [email protected]

Que protège le chiffrement, et que ne protège-t-il pas ?

Il protège les disques verrouillés : éteints, retirés pour être remplacés, ou laissés sur place après une résiliation. C'est le moment où l'hébergeur ou n'importe qui détient le matériel sans votre clé. Ce qui arrive aux disques après votre départ est détaillé sur les données après résiliation.

Tant que le serveur tourne déverrouillé, la clé réside en mémoire. Quelqu'un qui se connecte peut toujours supprimer des données ; ce risque est traité sur les sauvegardes immuables. Pour les données que le serveur n'a jamais besoin de lire, chiffrez sur votre propre machine avant l'envoi ; voir les sauvegardes chiffrées côté client.

Sur 23 vendeurs de serveurs de stockage Basalthold vérifiés le 2 November 2026, 2 exigeaient une pièce d'identité avant livraison et 12 pouvaient la demander selon certains déclencheurs. Le chiffrement protège les disques ; Sans KYC : pas de pièce d'identité, pas de selfie, pas de documents, pas de carte et pas de numéro de téléphone, à aucun moment.