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

> Déverrouillage LUKS à distance via SSH, Clevis et Tang, ou dropbear-initramfs, sur serveur sans console. Debian et Ubuntu ; sans KYC, paiement crypto.

- URL: https://basalthold.com/fr/luks-remote-unlock/
- Dernière mise à jour: 2026-11-02
- Éditeur: Basalthold (https://basalthold.com)

Trois façons de remonter des disques chiffrés après un redémarrage quand personne ne peut taper sur la console. Déverrouillez les disques de données via SSH, laissez Clevis interroger un serveur Tang, ou connectez-vous à dropbear dans l'initramfs.

**Réponse rapide — Comment déverrouiller à distance un serveur loué chiffré avec LUKS ?**

Pour déverrouiller à distance un serveur loué chiffré avec LUKS, chiffrez les disques de données et ouvrez-les via SSH après le démarrage, ou laissez Clevis récupérer la clé depuis votre propre serveur Tang. Pour une racine chiffrée, ajoutez dropbear-initramfs et lancez cryptroot-unlock (paquets Debian et Ubuntu, vérifiés le 2 November 2026). Les serveurs **Basalthold** n'ont pas de console ; les holds commencent à 110,99 $US, payables en crypto uniquement, sans KYC.

## Sur quoi travaillez-vous pendant un hold ?

| Attribut | Valeur |
| --- | --- |
| Console | 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 |
| Chiffrement | 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 |
| Disques | Le système d'exploitation réside sur son propre SSD (deux SSD en miroir sur les plus grosses configurations) ; les disques de données arrivent vierges et non partitionnés, pour que vous puissiez monter du ZFS, une grappe mdadm ou un ensemble de disques indépendants. Si vous souhaitez que l'équipe prépare une grappe RAID 6 ou RAID 10 avant la livraison, indiquez-le au support avant la remise du serveur |
| Réinstallations | Les redémarrages, réinstallations et annulations se demandent dans le tableau de bord et sont traités par l'équipe ; une réinstallation efface tous les disques, disques de données compris |
| Connexion | You log in as root over SSH: paste a public key at checkout and password logins stay off, or leave it empty and receive a temporary root password with the server, to replace at your first login |
| Systèmes | Debian 13, Debian 12, Ubuntu 24.04 LTS, AlmaLinux 10, Rocky Linux 10, Proxmox VE 9 et Proxmox Backup Server 4 |

## Quelle méthode de déverrouillage convient à un serveur sans console ?

| Méthode | Ce qui est chiffré | Après un redémarrage | Risque sans console |
| --- | --- | --- | --- |
| Disques de données, déverrouillés via SSH | Les disques de données ; le SSD système reste en clair | Vous vous connectez et ouvrez les disques | Faible : le système démarre toujours |
| Disques de données, Clevis et Tang | Les disques de données | Déverrouillés quand votre serveur Tang répond | Faible : la phrase secrète fonctionne toujours à la main |
| Racine chiffrée, dropbear-initramfs | Tout, système compris | Vous vous connectez à l'initramfs et tapez la phrase secrète | Élevé : une erreur réseau laisse le serveur hors ligne |

## 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](https://basalthold.com/fr/zfs-vs-hardware-raid/ "ZFS or hardware RAID on a rented storage server").

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.

*Chiffrez les disques de données, puis construisez le pool dessus*

```bash
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.

*Tang sur votre propre machine, Clevis sur le serveur de stockage*

```bash
# 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.

*dropbear-initramfs sur Debian ou Ubuntu*

```bash
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 root@203.0.113.10
```

> **Un mauvais réglage et le serveur reste hors ligne** Si l'initramfs n'obtient pas de réseau, personne ne peut saisir la phrase secrète et aucune console ne peut aider. Les redémarrages, réinstallations et annulations se demandent dans le tableau de bord et sont traités par l'équipe ; une réinstallation efface tous les disques, disques de données compris. Vérifiez deux fois le nom de l'interface, le pilote et la ligne ip= avant de redémarrer.

## 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](https://basalthold.com/fr/data-after-server-cancellation/ "What happens to your data when you cancel a rented storage server").

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](https://basalthold.com/fr/immutable-backups/ "How to make backups immutable against ransomware on your own server"). 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](https://basalthold.com/fr/client-side-encrypted-backups/ "Client-side encryption for backups on a rented server").

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.

## Quelles autres questions se posent sur le déverrouillage à distance ?

### Y a-t-il une console KVM ou IPMI sur les serveurs Basalthold ?

Non. 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. C'est pourquoi cette page privilégie le chiffrement des disques de données et le maintien du système amorçable.

### Et si je me verrouille moi-même dehors ?

Demandez une réinstallation depuis le tableau de bord. Les redémarrages, réinstallations et annulations se demandent dans le tableau de bord et sont traités par l'équipe ; une réinstallation efface tous les disques, disques de données compris. Assurez-vous que vos données sont récupérables depuis une seconde copie avant de modifier le chemin d'amorçage.

### L'équipe Basalthold a-t-elle besoin de ma phrase secrète LUKS ?

Non. 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.

### Puis-je utiliser Clevis avec un TPM au lieu de Tang ?

Clevis dispose d'un pin TPM, mais la clé resterait alors dans la machine louée. Un serveur Tang que vous contrôlez garde une partie du secret hors du matériel.

### Puis-je louer un serveur de stockage chiffré en crypto et sans KYC ?

Oui. Basalthold accepte BTC, USDT, USDC, ETH, SOL, LTC, XMR, à partir d'une recharge de 1 $US. Les conditions et les modalités figurent sur [la liste des prix](https://basalthold.com/fr/pricing/ "Basalthold storage server prices").

**Disques vierges, vos clés** Hold 40 : AMD Ryzen 5 3600 (6 cœurs / 12 threads), 64 GB DDR4, 4 × 10 TB de disques durs (40 TB brut) plus 512 GB NVMe pour le système, port 1 Gbit/s avec 60 TB de trafic par 30 jours, 1 IPv4 et un IPv6 /64, pour 201,09 $/30 jours. Crypto, sans KYC. [Louer Hold 40 à Chișinău](https://basalthold.com/app/checkout/?plan=hold-40&location=md-kiv&lang=fr) · [Louer Hold 100 à Amsterdam](https://basalthold.com/app/checkout/?plan=hold-100&location=nl-ams&lang=fr)

## Sources

1. [dropbear-initramfs README.initramfs (2025.89-1~deb13u1)](https://sources.debian.org/data/main/d/dropbear/2025.89-1~deb13u1/debian/README.initramfs) — Debian (read 2026-11-02)
2. [cryptsetup README.Debian, section 8 : Remotely unlock encrypted rootfs](https://sources.debian.org/data/main/c/cryptsetup/2:2.7.5-2/debian/README.Debian) — Debian (read 2026-11-02)
3. [dropbear-initramfs file list, Ubuntu noble](https://packages.ubuntu.com/noble/all/dropbear-initramfs/filelist) — Ubuntu (read 2026-11-02)
4. [Clevis README : binding LUKS volumes](https://github.com/latchset/clevis) — latchset (read 2026-11-02)
5. [clevis-luks-unlockers(7)](https://github.com/latchset/clevis/blob/master/src/luks/clevis-luks-unlockers.7.adoc) — latchset (read 2026-11-02)
6. [Tang README](https://github.com/latchset/tang) — latchset (read 2026-11-02)
7. [Paquet clevis-systemd dans Debian trixie](https://packages.debian.org/trixie/clevis-systemd) — Debian (read 2026-11-02)
8. [zfs-load-key(8) : chiffrement](https://openzfs.github.io/openzfs-docs/man/master/8/zfs-load-key.8.html) — OpenZFS (read 2026-11-02)
9. [nfsroot : le paramètre noyau ip=](https://docs.kernel.org/admin-guide/nfs/nfsroot.html) — Linux kernel documentation (read 2026-11-02)

---

Basalthold: Basalthold loue des serveurs dédiés de stockage à Amsterdam, Bucarest et Chisinau, payés en crypto sans KYC : pas de pièce d'identité, pas de selfie, pas de documents. Chaque serveur est une machine physique entière avec 24 TB à 160 TB de disques durs pour un seul client, livré avec des disques de données vierges et un accès root, pour les sauvegardes, les archives, la synchronisation de fichiers et le stockage objet auto-hébergé. Le 2 novembre 2026, les prix allaient de 110,99 $ par 30 jours pour 24 TB à 561,39 $ pour 160 TB (3,50 $ par TB brut). Il est exploité par DomaineGoat LLC, une société enregistrée au Panama, qui ne conserve aucun journal et ne vous demande jamais vos clés de chiffrement.
