Como desbloqueio remotamente um servidor alugado com criptografia LUKS?

Por que o desbloqueio remoto importa em um servidor alugado?

Porque um disco criptografado espera pela chave a cada boot, e ninguém está na tela. Não há acesso IPMI ou KVM-over-IP para clientes; reinicializações e reinstalações solicitadas no painel são executadas pela equipe.

Então planeje o desbloqueio antes de criptografar. Em uma reserva, o sistema operacional fica em seu próprio SSD e os discos de dados vêm vazios. Essa separação facilita o primeiro método: mantenha o sistema sem criptografia e criptografe os discos que guardam seus dados.

Criptografe os discos que guardam seus dados; mantenha o caminho de boot simples o bastante para corrigir via SSH.

Como criptografo os discos de dados e os desbloqueio depois de um reboot?

Formate cada disco de dados como LUKS2, abra-o e monte o array sobre os dispositivos abertos. A passphrase nunca toca o disco do servidor. Depois de um reboot, o sistema inicia, você faz login via SSH e abre os discos novamente. A escolha do array por cima está em ZFS ou RAID de hardware.

Os serviços que usam o pool esperam até você fazer isso. Uma checagem de uptime externa, ou um script que alerta quando o pool está ausente, avisa que houve um reboot.

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

A criptografia nativa do ZFS pode substituir o LUKS?

Sim, por dataset. Crie o dataset com encryption=on e uma passphrase, depois execute zfs load-key e zfs mount após cada reboot. Nenhum trabalho de initramfs é necessário.

Mas ela esconde menos. O manual do OpenZFS diz que o ZFS não criptografa os metadados da estrutura do pool: nomes de datasets e snapshots, propriedades e tamanhos de arquivos continuam legíveis. O LUKS criptografa o disco inteiro, incluindo os metadados. Ambos são cobertos pela mesma promessa: Você pode criptografar cada disco de dados com LUKS ou com a criptografia nativa do ZFS; as chaves ficam com você e ninguém da equipe pede por elas.

Como desbloqueio os discos automaticamente com Clevis e Tang?

Rode um servidor Tang em uma máquina que você controla em outro lugar e vincule cada disco a ele. O Clevis adiciona um novo slot de chave ao LUKS e armazena a chave criptografada no cabeçalho do LUKS. No boot, ele pede ao Tang que ajude a recuperar a chave; sua passphrase continua funcionando como antes.

O manual do Clevis diz que o desbloqueio no início do boot cobre apenas o volume raiz. Os discos de dados usam o desbloqueador de fim de boot, que lê /etc/crypttab. No Debian, o pacote clevis-systemd desbloqueia os dispositivos marcados com _netdev ali.

Os discos só abrem enquanto o servidor de armazenamento consegue alcançar o seu servidor Tang. Permita apenas o endereço IP do servidor de armazenamento no firewall do Tang. Discos que saem dessa rede ficam bloqueados.

# 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

Como desbloqueio uma raiz criptografada com dropbear-initramfs?

Coloque um pequeno servidor SSH, o dropbear, no initramfs. Ele inicia antes do sistema de arquivos raiz, você faz login com sua chave e o cryptroot-unlock pede a passphrase. O guia do cryptsetup do Debian descreve isso para sistemas headless.

O README do Debian define as regras. As chaves ficam em /etc/dropbear/initramfs/authorized_keys, e o login por senha fica desativado. As opções ficam em /etc/dropbear/initramfs/dropbear.conf. O driver de rede precisa estar em /etc/initramfs-tools/modules, e um endereço estático é definido com o parâmetro ip= do kernel. Os mesmos caminhos valem no Debian 12, no Debian 13 e no Ubuntu 24.04.

O initramfs usa suas próprias chaves de host, então seu cliente SSH avisa sobre uma chave alterada. Mantenha um arquivo known_hosts separado para ele, como o README sugere.

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]

O que a criptografia protege, e o que não protege?

Ela protege discos que estão bloqueados: desligados, retirados para troca ou deixados para trás após um cancelamento. É quando o host ou qualquer outra pessoa tem o hardware sem a sua chave. O que acontece com os discos depois que você sai está em dados após cancelamento.

Enquanto o servidor roda desbloqueado, a chave fica na memória. Quem fizer login ainda pode apagar dados; esse risco está coberto em backups imutáveis. Para dados que o servidor nunca precisa ler, criptografe na sua própria máquina antes do upload; veja backups criptografados do lado do cliente.

De 23 vendedores de servidores de armazenamento que Basalthold verificou em 2 November 2026, 2 exigiram documento antes da entrega e 12 podiam pedi-lo em certos gatilhos. A criptografia protege os discos; Sem KYC: sem documento de identidade, sem selfie, sem documentos, sem cartão e sem número de telefone, em nenhum momento.