Jak zdalnie odblokować zaszyfrowany LUKS-em wynajęty serwer?

Dlaczego zdalne odblokowywanie ma znaczenie na wynajętym serwerze?

Bo zaszyfrowany dysk czeka na swój klucz przy każdym rozruchu, a przy ekranie nikogo nie ma. Klienci nie mają dostępu przez IPMI ani KVM-over-IP; restarty i reinstalacje, o które prosisz w panelu, wykonuje zespół.

Zaplanuj więc odblokowywanie, zanim zaszyfrujesz. Na dzierżawie system operacyjny leży na własnym SSD, a dyski danych przychodzą puste. Ten podział ułatwia pierwszą metodę: zostaw system jawny, zaszyfruj dyski, na których trzymasz dane.

Zaszyfruj dyski, na których trzymasz dane; utrzymuj ścieżkę rozruchu na tyle prostą, by naprawić ją przez SSH.

Jak zaszyfrować dyski danych i odblokować je po restarcie?

Sformatuj każdy dysk danych jako LUKS2, otwórz go i zbuduj macierz na otwartych urządzeniach. Hasło nigdy nie trafia na dysk serwera. Po restarcie system wstaje, logujesz się przez SSH i ponownie otwierasz dyski. Wybór macierzy na wierzchu opisano w ZFS lub sprzętowy RAID.

Usługi, które korzystają z puli, czekają, aż to zrobisz. Zewnętrzny monitoring dostępności albo skrypt, który alarmuje przy braku puli, powie Ci, że nastąpił restart.

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

Czy natywne szyfrowanie ZFS może zastąpić LUKS?

Tak, dla każdego zbioru danych osobno. Utwórz zbiór danych z encryption=on i hasłem, a potem uruchamiaj zfs load-key i zfs mount po każdym restarcie. Praca z initramfs nie jest potrzebna.

Ukrywa jednak mniej. Podręcznik OpenZFS mówi, że ZFS nie szyfruje metadanych struktury puli: nazwy zbiorów danych i snapshotów, właściwości i rozmiary plików pozostają czytelne. LUKS szyfruje cały dysk, łącznie z metadanymi. Oba objęte są tą samą obietnicą: Możesz zaszyfrować każdy dysk danych za pomocą LUKS lub natywnego szyfrowania ZFS; klucze pozostają u Ciebie i nikt z zespołu nigdy o nie nie prosi.

Jak automatycznie odblokować dyski za pomocą Clevis i Tang?

Uruchom serwer Tang na maszynie, którą kontrolujesz gdzie indziej, i powiąż z nim każdy dysk. Clevis dodaje nowy slot klucza do LUKS i zapisuje zaszyfrowany klucz w nagłówku LUKS. Przy rozruchu prosi Tang o pomoc w odzyskaniu klucza; Twoje hasło nadal działa jak wcześniej.

Podręcznik Clevis mówi, że odblokowywanie we wczesnej fazie rozruchu obejmuje tylko wolumen root. Dyski danych korzystają z odblokowywania w późnej fazie rozruchu, które odczytuje /etc/crypttab. W Debianie pakiet clevis-systemd odblokowuje tam urządzenia oznaczone _netdev.

Dyski otwierają się tylko wtedy, gdy serwer storage może połączyć się z Twoim serwerem Tang. Przepuść przez firewall Tanga wyłącznie adres IP serwera storage. Dyski, które opuszczą tę sieć, pozostają zablokowane.

# 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

Jak odblokować zaszyfrowany root za pomocą dropbear-initramfs?

Umieść mały serwer SSH, dropbear, w initramfs. Uruchamia się przed systemem plików root, logujesz się swoim kluczem, a cryptroot-unlock prosi o passphrase. Przewodnik Debian cryptsetup opisuje to dla systemów headless.

README Debiana ustala zasady. Klucze trafiają do /etc/dropbear/initramfs/authorized_keys, a logowanie hasłem jest wyłączone. Opcje trafiają do /etc/dropbear/initramfs/dropbear.conf. Sterownik sieci musi być w /etc/initramfs-tools/modules, a statyczny adres ustawia się parametrem jądra ip=. Te same ścieżki obowiązują w Debian 12, Debian 13 i Ubuntu 24.04.

initramfs używa własnych kluczy hosta, więc Twój klient SSH ostrzeże o zmienionym kluczu. Prowadź dla niego osobny plik known_hosts, jak sugeruje 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]

Co chroni szyfrowanie, a czego nie?

Chroni dyski, które są zablokowane: wyłączone, wyjęte do wymiany albo pozostawione po anulowaniu. Wtedy host lub ktokolwiek inny ma sprzęt bez Twojego klucza. Co dzieje się z dyskami po Twoim odejściu, opisano na dane po anulowaniu.

Gdy serwer działa odblokowany, klucz siedzi w pamięci. Ktoś, kto się zaloguje, nadal może usunąć dane; to ryzyko opisano na niezmienne kopie zapasowe. Dane, których serwer nigdy nie musi czytać, zaszyfruj na własnej maszynie przed wysłaniem; patrz kopie zapasowe szyfrowane po stronie klienta.

Ze 23 sprzedawców serwerów storage Basalthold sprawdzonych na 2 November 2026, 2 wymagało dokumentu tożsamości przed dostawą, a 12 mogło o niego poprosić przy pewnych przesłankach. Szyfrowanie chroni dyski; Bez KYC: żadnego dowodu, żadnego selfie, żadnych dokumentów, żadnej karty i żadnego numeru telefonu, na żadnym etapie.