Як розблокувати LUKS-зашифрований орендований сервер віддалено?

Чому віддалене розблокування важливе на орендованому сервері?

Бо зашифрований диск чекає на свій ключ при кожному завантаженні, а біля екрана нікого немає. Для клієнтів немає доступу IPMI або KVM-over-IP; перезавантаження та перевстановлення, які ви запитуєте в дашборді, виконує команда.

Тож продумайте розблокування ще до шифрування. На оренді операційна система живе на власному SSD, а диски з даними надходять порожніми. Цей поділ спрощує перший спосіб: залиште систему незашифрованою, зашифруйте диски, де лежать ваші дані.

Шифруйте диски, де лежать ваші дані; тримайте шлях завантаження достатньо простим, щоб полагодити його через SSH.

Як зашифрувати диски з даними і розблокувати їх після перезавантаження?

Відформатуйте кожен диск з даними як LUKS2, відкрийте його і побудуйте масив на відкритих пристроях. Парольна фраза ніколи не потрапляє на диск сервера. Після перезавантаження система піднімається, ви входите через SSH і знову відкриваєте диски. Вибір масиву зверху — це ZFS або апаратний RAID.

Сервіси, що користуються пулом, чекатимуть, поки ви це зробите. Зовнішня перевірка доступності або скрипт, що сповіщає, коли пул відсутній, підкаже, що сталося перезавантаження.

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

Чи може власне шифрування ZFS замінити LUKS?

Так, для кожного датасету. Створіть датасет з encryption=on і парольною фразою, потім запускайте zfs load-key і zfs mount після кожного перезавантаження. Роботи з initramfs не потрібно.

Але приховує воно менше. Посібник OpenZFS каже, що ZFS не шифрує метадані структури пулу: назви датасетів і снапшотів, властивості та розміри файлів залишаються читабельними. LUKS шифрує весь диск, включно з метаданими. Обидва підпадають під ту саму обіцянку: Ви можете зашифрувати кожен диск для даних за допомогою LUKS або вбудованого шифрування ZFS; ключі залишаються у вас, і ніхто з команди їх ніколи не запитує.

Як розблокувати диски автоматично за допомогою Clevis і Tang?

Запустіть сервер Tang на машині, яку ви контролюєте деінде, і прив'яжіть до нього кожен диск. Clevis додає новий слот ключа до LUKS і зберігає зашифрований ключ у заголовку LUKS. Під час завантаження він просить Tang допомогти відновити ключ; ваша парольна фраза працює як і раніше.

Посібник Clevis каже, що розблокування на ранній стадії завантаження охоплює лише кореневий том. Диски з даними використовують розблокувач на пізній стадії, який читає /etc/crypttab. У Debian пакет clevis-systemd розблоковує там пристрої, позначені _netdev.

Диски відкриваються, лише поки сервер зберігання може дістатися до вашого сервера Tang. Пропустіть через фаєрвол Tang лише IP-адресу сервера зберігання. Диски, що вийшли з цієї мережі, залишаються заблокованими.

# 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

Як розблокувати зашифрований корінь за допомогою dropbear-initramfs?

Додайте невеликий SSH-сервер dropbear в initramfs. Він запускається до кореневої файлової системи, ви входите зі своїм ключем, і cryptroot-unlock запитує парольну фразу. Посібник Debian з cryptsetup описує це для headless-систем.

README Debian задає правила. Ключі кладуться в /etc/dropbear/initramfs/authorized_keys, а вхід за паролем вимкнено. Опції йдуть у /etc/dropbear/initramfs/dropbear.conf. Мережевий драйвер має бути в /etc/initramfs-tools/modules, а статична адреса задається параметром ядра ip=. Ті самі шляхи діють на Debian 12, Debian 13 і Ubuntu 24.04.

initramfs використовує власні host-ключі, тож ваш SSH-клієнт попереджає про змінений ключ. Тримайте для нього окремий файл known_hosts, як радить 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]

Що шифрування захищає, а що ні?

Воно захищає заблоковані диски: вимкнені, витягнуті для заміни або залишені після скасування. Саме тоді хост або будь-хто інший має обладнання без вашого ключа. Що відбувається з дисками після того, як ви йдете, описано на дані після скасування.

Поки сервер працює незаблокованим, ключ лежить у пам'яті. Той, хто увійде, все ще може видалити дані; цей ризик покрито на незмінні резервні копії. Для даних, які серверу ніколи не потрібно читати, шифруйте на власній машині перед завантаженням; див. резервні копії, зашифровані на клієнті.

З 23 продавців сховищних серверів Basalthold перевірено на 2 November 2026, 2 вимагали ID до доставки, а 12 могли попросити його за тригерами. Шифрування захищає диски; Без KYC: ні ID, ні селфі, ні документів, ні картки й ні номера телефону — на жодному етапі.