# How do I unlock a LUKS-encrypted rented server remotely? > LUKS remote unlock on a rented server without a console: data drives by SSH, Clevis and Tang, or dropbear-initramfs. Debian and Ubuntu; no KYC, crypto. - URL: https://basalthold.com/luks-remote-unlock/ - Last updated: 2026-11-02 - Publisher: Basalthold (https://basalthold.com) Three ways to bring encrypted drives back after a reboot when nobody can type at the console. Unlock the data drives over SSH, let Clevis ask a Tang server, or log into dropbear inside the initramfs. **Quick answer — How do I unlock a LUKS-encrypted rented server remotely?** To unlock a LUKS-encrypted rented server remotely, encrypt the data drives and open them over SSH after boot, or let Clevis fetch the key from your own Tang server. For an encrypted root, add dropbear-initramfs and run cryptroot-unlock (Debian and Ubuntu packages, checked 2 November 2026). **Basalthold** servers have no console; holds start at $110.99, crypto only, no KYC. ## What do you work with on a hold? | Attribute | Value | | --- | --- | | Console | There is no IPMI or KVM-over-IP access for customers; reboots and reinstalls you request in the dashboard are carried out by the team | | Encryption | You can encrypt every data drive with LUKS or ZFS native encryption; the keys stay with you and nobody on the team ever asks for them | | Drives | The operating system sits on its own SSD (two mirrored SSDs on the larger holds); the data drives arrive blank and unpartitioned, so you can build ZFS, an mdadm array or a set of independent disks. If you want the team to prepare a RAID 6 or RAID 10 array before delivery, say so to support before the server is handed over | | Reinstalls | Reboots, reinstalls and cancellations are requested in the dashboard and handled by the team; a reinstall wipes every drive, data drives included | | 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 | | Systems | Debian 13, Debian 12, Ubuntu 24.04 LTS, AlmaLinux 10, Rocky Linux 10, Proxmox VE 9 and Proxmox Backup Server 4 | ## Which unlock method fits a server without a console? | Method | What is encrypted | After a reboot | Risk without a console | | --- | --- | --- | --- | | Data drives, unlocked by SSH | The data drives; the system SSD stays plain | You log in and open the drives | Low: the system always boots | | Data drives, Clevis and Tang | The data drives | Unlocked when your Tang server answers | Low: the passphrase still works by hand | | Encrypted root, dropbear-initramfs | Everything, system included | You log into the initramfs and type the passphrase | High: a network mistake keeps the server offline | ## Why does remote unlock matter on a rented server? Because an encrypted drive waits for its key at every boot, and nobody is at the screen. There is no IPMI or KVM-over-IP access for customers; reboots and reinstalls you request in the dashboard are carried out by the team. So plan the unlock before you encrypt. On a hold, the operating system lives on its own SSD and the data drives come blank. That split makes the first method easy: keep the system plain, encrypt the drives that hold your data. **Encrypt the drives that hold your data; keep the boot path simple enough to fix over SSH.** ## How do I encrypt the data drives and unlock them after a reboot? Format each data drive as LUKS2, open it, and build the array on the opened devices. The passphrase never touches the server's disk. After a reboot, the system comes up, you log in over SSH, and you open the drives again. The array choice on top is on [ZFS or hardware RAID](https://basalthold.com/zfs-vs-hardware-raid/ "ZFS or hardware RAID on a rented storage server"). Services that use the pool wait until you do. An outside uptime check, or a script that alerts when the pool is missing, tells you a reboot happened. *Encrypt the data drives, then build the pool on them* ```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 ``` ## Can ZFS native encryption replace LUKS? Yes, per dataset. Create the dataset with `encryption=on` and a passphrase, then run `zfs load-key` and `zfs mount` after each reboot. No initramfs work is needed. It hides less, though. The OpenZFS manual says ZFS does not encrypt pool-structure metadata: dataset and snapshot names, properties and file sizes stay readable. LUKS encrypts the whole drive, metadata included. Both are covered by the same promise: You can encrypt every data drive with LUKS or ZFS native encryption; the keys stay with you and nobody on the team ever asks for them. ## How do I unlock the drives automatically with Clevis and Tang? Run a Tang server on a machine you control elsewhere, and bind each drive to it. Clevis adds a new key slot to LUKS and stores the encrypted key in the LUKS header. At boot it asks Tang to help recover the key; your passphrase keeps working as before. The Clevis manual says early-boot unlocking only covers the root volume. Data drives use the late-boot unlocker, which reads `/etc/crypttab`. On Debian, the clevis-systemd package unlocks devices marked `_netdev` there. The drives open only while the storage server can reach your Tang server. Allow only the storage server's IP address through Tang's firewall. Drives that leave that network stay locked. *Tang on your own machine, Clevis on the storage server* ```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 ``` ## How do I unlock an encrypted root with dropbear-initramfs? Put a small SSH server, dropbear, into the initramfs. It starts before the root filesystem, you log in with your key, and `cryptroot-unlock` asks for the passphrase. Debian's cryptsetup guide describes this for headless systems. The Debian README sets the rules. Keys go in `/etc/dropbear/initramfs/authorized_keys`, and password logins are off. Options go in `/etc/dropbear/initramfs/dropbear.conf`. The network driver must be in `/etc/initramfs-tools/modules`, and a static address is set with the kernel's `ip=` parameter. The same paths apply on Debian 12, Debian 13 and Ubuntu 24.04. The initramfs uses its own host keys, so your SSH client warns about a changed key. Keep a separate known_hosts file for it, as the README suggests. *dropbear-initramfs on Debian or 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 ``` > **One wrong setting keeps the server offline** If the initramfs gets no network, nobody can type the passphrase and no console can help. Reboots, reinstalls and cancellations are requested in the dashboard and handled by the team; a reinstall wipes every drive, data drives included. Check the interface name, the driver and the ip= line twice before you reboot. ## What does encryption protect, and what not? It protects drives that are locked: powered off, pulled for replacement, or left behind after a cancellation. That is when the host or anyone else holds the hardware without your key. What happens to drives after you leave is on [data after cancellation](https://basalthold.com/data-after-server-cancellation/ "What happens to your data when you cancel a rented storage server"). While the server runs unlocked, the key sits in memory. Someone who logs in can still delete data; that risk is covered on [immutable backups](https://basalthold.com/immutable-backups/ "How to make backups immutable against ransomware on your own server"). For data that the server never needs to read, encrypt on your own machine before upload; see [client-side encrypted backups](https://basalthold.com/client-side-encrypted-backups/ "Client-side encryption for backups on a rented server"). Of 23 storage-server sellers Basalthold checked on 2 November 2026, 2 required ID before delivery and 12 could ask for it on triggers. Encryption protects the drives; No KYC: no ID, no selfie, no documents, no card and no phone number, at any point. ## What else do people ask about remote unlock? ### Is there a KVM or IPMI console on Basalthold servers? No. There is no IPMI or KVM-over-IP access for customers; reboots and reinstalls you request in the dashboard are carried out by the team. That is why this page favours encrypting the data drives and keeping the system bootable. ### What if I lock myself out? Request a reinstall in the dashboard. Reboots, reinstalls and cancellations are requested in the dashboard and handled by the team; a reinstall wipes every drive, data drives included. Keep your data recoverable from a second copy before you change the boot path. ### Does the Basalthold team need my LUKS passphrase? No. You can encrypt every data drive with LUKS or ZFS native encryption; the keys stay with you and nobody on the team ever asks for them. ### Can I use Clevis with a TPM instead of Tang? Clevis has a TPM pin, but the key would then stay inside the rented machine. A Tang server you control keeps part of the secret away from the hardware. ### Can I rent an encrypted storage server with crypto and no KYC? Yes. Basalthold takes BTC, USDT, USDC, ETH, SOL, LTC, from a top-up of $25. Holds and terms are on [the price list](https://basalthold.com/pricing/ "Basalthold storage server prices"). **Blank drives, your keys** Hold 40: AMD Ryzen 5 3600 (6 cores / 12 threads), 64 GB DDR4, 4 × 10 TB hard drives (40 TB raw) plus 512 GB NVMe for the system, 1 Gbit/s port with 60 TB of traffic per 30 days, 1 IPv4 and an IPv6 /64, for $201.09/30 days. Crypto, no KYC. [Rent Hold 40 in Chisinau](https://basalthold.com/app/checkout/?plan=hold-40&location=md-kiv&lang=en) · [Rent Hold 100 in Amsterdam](https://basalthold.com/app/checkout/?plan=hold-100&location=nl-ams&lang=en) ## Sources 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, section 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. [dropbear-initramfs file list, 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. [Package clevis-systemd in 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: the ip= kernel parameter](https://docs.kernel.org/admin-guide/nfs/nfsroot.html) — Linux kernel documentation (read 2026-11-02) --- Basalthold: Basalthold rents storage dedicated servers in Amsterdam, Bucharest and Chisinau, paid in crypto with no KYC: no ID, no selfie, no documents. Each server is a whole physical machine with 24 TB to 160 TB of hard drives for one customer, delivered with blank data drives and root access, for backups, archives, file sync and self-hosted object storage. On 2 November 2026, prices ran from $110.99 per 30 days for 24 TB to $561.39 for 160 TB ($3.50 per raw TB). It is run by DomaineGoat LLC, a company registered in Panama, keeps no logs and never asks for your encryption keys.