Come sblocco da remoto un server noleggiato con LUKS?

Perché lo sblocco remoto conta su un server noleggiato?

Perché un disco cifrato aspetta la sua chiave a ogni boot, e nessuno è davanti allo schermo. Non c'è accesso IPMI o KVM-over-IP per i clienti; i riavvii e le reinstallazioni che richiedi nella dashboard vengono eseguiti dal team.

Quindi pianifica lo sblocco prima di cifrare. In un noleggio, il sistema operativo vive sul suo SSD e i dischi dati arrivano vuoti. Questa separazione rende facile il primo metodo: lascia il sistema in chiaro, cifra i dischi che contengono i tuoi dati.

Cifra i dischi che contengono i tuoi dati; tieni il percorso di boot abbastanza semplice da poterlo sistemare via SSH.

Come cifro i dischi dati e li sblocco dopo un riavvio?

Formatta ogni disco dati come LUKS2, aprilo e costruisci l'array sui dispositivi aperti. La passphrase non tocca mai il disco del server. Dopo un riavvio, il sistema si avvia, accedi via SSH e riapri i dischi. La scelta dell'array sopra è su ZFS o RAID hardware.

I servizi che usano il pool aspettano che lo faccia tu. Un controllo di uptime esterno, o uno script che avvisa quando il pool manca, ti dice che c'è stato un riavvio.

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

La crittografia nativa di ZFS può sostituire LUKS?

Sì, per dataset. Crea il dataset con encryption=on e una passphrase, poi esegui zfs load-key e zfs mount dopo ogni riavvio. Non serve alcun lavoro sull'initramfs.

Però nasconde meno. Il manuale OpenZFS dice che ZFS non cifra i metadati della struttura del pool: i nomi di dataset e snapshot, le proprietà e le dimensioni dei file restano leggibili. LUKS cifra l'intero disco, metadati inclusi. Entrambi sono coperti dalla stessa promessa: Puoi cifrare ogni disco dati con LUKS o la crittografia nativa di ZFS; le chiavi restano con te e nessuno del team te le chiede mai.

Come sblocco i dischi automaticamente con Clevis e Tang?

Esegui un server Tang su una macchina che controlli altrove e collega ogni disco ad esso. Clevis aggiunge un nuovo key slot a LUKS e memorizza la chiave cifrata nell'header LUKS. Al boot chiede a Tang di aiutare a recuperare la chiave; la tua passphrase continua a funzionare come prima.

Il manuale di Clevis dice che lo sblocco in early-boot copre solo il volume root. I dischi dati usano l'unlocker in late-boot, che legge /etc/crypttab. Su Debian, il pacchetto clevis-systemd sblocca i dispositivi contrassegnati _netdev lì.

I dischi si aprono solo finché il server di storage raggiunge il tuo server Tang. Consenti solo l'indirizzo IP del server di storage nel firewall di Tang. I dischi che escono da quella rete restano bloccati.

# 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

Come sblocco una root cifrata con dropbear-initramfs?

Inserisci un piccolo server SSH, dropbear, nell'initramfs. Si avvia prima del filesystem root, accedi con la tua chiave e cryptroot-unlock chiede la passphrase. La guida di Debian a cryptsetup lo descrive per i sistemi headless.

Il README di Debian stabilisce le regole. Le chiavi vanno in /etc/dropbear/initramfs/authorized_keys e gli accessi con password sono disattivati. Le opzioni vanno in /etc/dropbear/initramfs/dropbear.conf. Il driver di rete deve essere in /etc/initramfs-tools/modules e un indirizzo statico si imposta con il parametro ip= del kernel. Gli stessi percorsi valgono su Debian 12, Debian 13 e Ubuntu 24.04.

L'initramfs usa le proprie host key, quindi il tuo client SSH avvisa che la chiave è cambiata. Tienine un file known_hosts separato, come suggerisce il 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]

Cosa protegge la crittografia e cosa no?

Protegge i dischi bloccati: spenti, rimossi per la sostituzione o lasciati indietro dopo una disdetta. È allora che il provider o chiunque altro ha l'hardware senza la tua chiave. Cosa succede ai dischi dopo che te ne vai è spiegato in dati dopo la disdetta.

Mentre il server è acceso e sbloccato, la chiave resta in memoria. Chi effettua l'accesso può comunque cancellare dati; quel rischio è trattato in backup immutabili. Per i dati che il server non deve mai leggere, crittografa sulla tua macchina prima del caricamento; vedi backup crittografati lato client.

Di 23 venditori di server di storage Basalthold verificati il 2 November 2026, 2 richiedevano un documento prima della consegna e 12 potevano chiederlo al verificarsi di alcuni trigger. La crittografia protegge i dischi; Nessun KYC: nessun documento d'identità, nessun selfie, nessun documento, nessuna carta e nessun numero di telefono, in nessun momento.