# Como desbloqueio remotamente um servidor alugado com criptografia LUKS? > Desbloqueio remoto do LUKS em um servidor alugado sem console: discos de dados via SSH, Clevis e Tang, ou dropbear-initramfs. Debian e Ubuntu; sem KYC, cripto. - URL: https://basalthold.com/pt/luks-remote-unlock/ - Última atualização: 2026-11-02 - Editor: Basalthold (https://basalthold.com) Três formas de reativar discos criptografados depois de um reboot quando ninguém pode digitar no console. Desbloqueie os discos de dados via SSH, deixe o Clevis consultar um servidor Tang ou faça login no dropbear dentro do initramfs. **Resposta rápida — Como desbloqueio remotamente um servidor alugado com criptografia LUKS?** Para desbloquear remotamente um servidor alugado com criptografia LUKS, criptografe os discos de dados e abra-os via SSH depois do boot, ou deixe o Clevis buscar a chave no seu próprio servidor Tang. Para uma raiz criptografada, adicione o dropbear-initramfs e execute cryptroot-unlock (pacotes Debian e Ubuntu, verificado em 2 November 2026). Os servidores **Basalthold** não têm console; as reservas começam a partir de US$ 110,99, somente cripto, sem KYC. ## Com o que você trabalha em uma reserva? | Atributo | Valor | | --- | --- | | Console | Não há acesso IPMI ou KVM-over-IP para clientes; reinicializações e reinstalações solicitadas no painel são executadas pela equipe | | Criptografia | 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 | | Discos | O sistema operacional fica em um SSD próprio (dois SSDs espelhados no modelo maior); os discos de dados chegam vazios e sem partição, para você montar ZFS, um array mdadm ou um conjunto de discos independentes. Se quiser que a equipe prepare um array RAID 6 ou RAID 10 antes da entrega, avise o suporte antes da entrega do servidor | | Reinstalações | Reinicializações, reinstalações e cancelamentos são solicitados no painel e tratados pela equipe; uma reinstalação apaga todos os discos, inclusive os de dados | | Login | 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 | | Sistemas | Debian 13, Debian 12, Ubuntu 24.04 LTS, AlmaLinux 10, Rocky Linux 10, Proxmox VE 9 e Proxmox Backup Server 4 | ## Qual método de desbloqueio serve para um servidor sem console? | Método | O que fica criptografado | Depois de um reboot | Risco sem console | | --- | --- | --- | --- | | Discos de dados, desbloqueados por SSH | Os discos de dados; o SSD do sistema fica sem criptografia | Você faz login e abre os discos | Baixo: o sistema sempre inicia | | Discos de dados, Clevis e Tang | Os discos de dados | Desbloqueados quando o seu servidor Tang responde | Baixo: a passphrase ainda funciona manualmente | | Raiz criptografada, dropbear-initramfs | Tudo, inclusive o sistema | Você faz login no initramfs e digita a passphrase | Alto: um erro de rede mantém o servidor offline | ## 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](https://basalthold.com/pt/zfs-vs-hardware-raid/ "ZFS or hardware RAID on a rented storage server"). 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. *Criptografe os discos de dados e monte o pool sobre eles* ```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 ``` ## 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. *Tang na sua própria máquina, Clevis no servidor de armazenamento* ```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 ``` ## 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. *dropbear-initramfs no 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 ``` > **Uma configuração errada mantém o servidor offline** Se o initramfs não conseguir rede, ninguém consegue digitar a passphrase e nenhum console ajuda. Reinicializações, reinstalações e cancelamentos são solicitados no painel e tratados pela equipe; uma reinstalação apaga todos os discos, inclusive os de dados. Confira o nome da interface, o driver e a linha ip= duas vezes antes de reiniciar. ## 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](https://basalthold.com/pt/data-after-server-cancellation/ "What happens to your data when you cancel a rented storage server"). 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](https://basalthold.com/pt/immutable-backups/ "How to make backups immutable against ransomware on your own server"). 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](https://basalthold.com/pt/client-side-encrypted-backups/ "Client-side encryption for backups on a rented server"). 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. ## O que mais as pessoas perguntam sobre desbloqueio remoto? ### Existe console KVM ou IPMI nos servidores Basalthold? Não. Não há acesso IPMI ou KVM-over-IP para clientes; reinicializações e reinstalações solicitadas no painel são executadas pela equipe. É por isso que esta página prefere criptografar os discos de dados e manter o sistema inicializável. ### E se eu me trancar fora? Solicite uma reinstalação no dashboard. Reinicializações, reinstalações e cancelamentos são solicitados no painel e tratados pela equipe; uma reinstalação apaga todos os discos, inclusive os de dados. Mantenha seus dados recuperáveis a partir de uma segunda cópia antes de alterar o caminho de boot. ### A equipe Basalthold precisa da minha passphrase LUKS? Não. 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. ### Posso usar Clevis com um TPM em vez de Tang? O Clevis tem um pin de TPM, mas então a chave ficaria dentro da máquina alugada. Um servidor Tang que você controla mantém parte do segredo fora do hardware. ### Posso alugar um servidor de armazenamento criptografado com cripto e sem KYC? Sim. Basalthold aceita BTC, USDT, USDC, ETH, SOL, LTC, XMR, a partir de uma recarga de US$ 1. Retenções e termos estão em [a lista de preços](https://basalthold.com/pt/pricing/ "Basalthold storage server prices"). **Discos em branco, suas chaves** Hold 40: AMD Ryzen 5 3600 (6 núcleos / 12 threads), 64 GB DDR4, 4 × 10 TB de discos rígidos (40 TB brutos) mais SSD NVMe de 512 GB para o sistema, porta de 1 Gbit/s com 60 TB de tráfego por 30 dias, 1 IPv4 e um IPv6 /64, por $201.09/30 dias. Cripto, sem KYC. [Alugar Hold 40 em Chisinau](https://basalthold.com/app/checkout/?plan=hold-40&location=md-kiv&lang=pt) · [Alugue Hold 100 em Amsterdã](https://basalthold.com/app/checkout/?plan=hold-100&location=nl-ams&lang=pt) ## Fontes 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, seção 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. [lista de arquivos do dropbear-initramfs, 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. [Pacote clevis-systemd no Debian trixie](https://packages.debian.org/trixie/clevis-systemd) — Debian (read 2026-11-02) 8. [zfs-load-key(8): encryption](https://openzfs.github.io/openzfs-docs/man/master/8/zfs-load-key.8.html) — OpenZFS (read 2026-11-02) 9. [nfsroot: o parâmetro de kernel ip=](https://docs.kernel.org/admin-guide/nfs/nfsroot.html) — Linux kernel documentation (read 2026-11-02) --- Basalthold: A Basalthold aluga servidores dedicados de armazenamento em Amsterdã, Bucareste e Chisinau, pagos em cripto e sem KYC: sem documento, sem selfie, sem comprovantes. Cada servidor é uma máquina física inteira com 24 TB a 160 TB de discos rígidos para um único cliente, entregue com discos de dados em branco e acesso root, para backups, arquivos, sincronização de arquivos e armazenamento de objetos auto-hospedado. Em 2 de novembro de 2026, os preços iam de $110.99 por 30 dias para 24 TB a $561.39 para 160 TB ($3.50 por TB bruto). É operado pela DomaineGoat LLC, uma empresa registrada no Panamá, não mantém logs e nunca pede suas chaves de criptografia.