Applies to: Ubuntu 26.04 (cryptsetup 2.8.4) and Ubuntu 24.04 (cryptsetup 2.7.0), LUKS2; formatting, key slots and header backups tested on an image file, opening and mounting a real disk according to the cryptsetup manual
Ubuntu encrypts disks with LUKS, managed by the cryptsetup command. There are two ways to use it:
- Full disk encryption of the system disk, chosen in the installer. You must type a passphrase at every boot, before SSH is running.
- Encrypting a data disk, partition or container file after installation. The server boots normally and you unlock the encrypted data when you need it.
On a VPS or dedicated server the second way is usually the practical one, because a server with an encrypted system disk stops at the passphrase prompt after every reboot until someone types it in a console. Both are covered below.
What disk encryption protects
LUKS protects data at rest: a disk that is removed, replaced, decommissioned or copied while locked is unreadable without the passphrase. It doesn’t protect data while the volume is unlocked and mounted: anyone with root access to the running server can read the files. For protection while the server runs, keep the system patched and access locked down.
Encrypt a data disk with LUKS
Warning: luksFormat destroys everything on the device. Back up first, and check the device name twice.
- Install cryptsetup if it isn’t there yet:
sudo apt install cryptsetup
- Find the disk with
lsblk. An empty second disk might be/dev/sdb,/dev/vdbor/dev/nvme1n1; it must have no mount point. We use/dev/sdbbelow. - Create the LUKS volume. Type
YESin capital letters, then choose a long passphrase:$ sudo cryptsetup luksFormat /dev/sdb WARNING! ======== This will overwrite data on /dev/sdb irrevocably. Are you sure? (Type 'yes' in capital letters): YES Enter passphrase for /dev/sdb: Verify passphrase:
(Our test ran on an image file; the device name in the output is shown as/dev/sdb.) - Unlock it. This creates the device
/dev/mapper/securedata, which shows the decrypted data:sudo cryptsetup open /dev/sdb securedata
- Create a file system on the unlocked device (not on
/dev/sdbitself):sudo mkfs.ext4 /dev/mapper/securedata
- Mount it:
sudo mkdir -p /srv/secure sudo mount /dev/mapper/securedata /srv/secure
Files you save in /srv/secure are now encrypted on the disk. To lock the volume again, unmount it and close it. close removes /dev/mapper/securedata and, according to the cryptsetup manual, “wipes the key from kernel memory”:
sudo umount /srv/secure sudo cryptsetup close securedata
Check the LUKS header
sudo cryptsetup luksDump /dev/sdb shows how the volume is set up. With the defaults of cryptsetup 2.8.4 on Ubuntu 26.04 our test volume used:
Version: 2 ... cipher: aes-xts-plain64 ... Keyslots: 0: luks2 Key: 512 bits PBKDF: argon2id (lab sample, shortened)
That is AES in XTS mode with a 512-bit key (AES-256, which Ubuntu’s security documentation names as the default), and Argon2id to turn your passphrase into a key. cryptsetup measures the machine when it formats, so the time and memory settings of the passphrase check differ from server to server. sudo cryptsetup isLuks -v /dev/sdb prints Command successful. for a LUKS device.
After a reboot: unlock by hand
The simplest and safest setup for a server: after each reboot, log in over SSH and unlock the disk yourself. Use the UUID, because device names like /dev/sdb can change between boots:
sudo cryptsetup luksUUID /dev/sdb sudo cryptsetup open /dev/disk/by-uuid/YOUR-UUID securedata sudo mount /dev/mapper/securedata /srv/secure
Start the services that use the data (database, application) after this, not at boot.
If you also want the volume listed in /etc/crypttab, add noauto:
securedata UUID=YOUR-UUID none luks,noauto
Without noauto, a none entry means the passphrase “has to be manually entered during system boot” (systemd crypttab manual), so the server would wait at the console. We checked with systemd’s crypttab generator on Ubuntu 26.04: with noauto the unlock unit is created but not started at boot. Ubuntu’s cryptsetup package also includes cryptdisks_start, so sudo cryptdisks_start securedata unlocks an entry from crypttab by name.
Or: unlock automatically with a key file
If services must start on their own after a reboot, add a key file as a second key and let the system use it at boot:
sudo dd if=/dev/urandom of=/root/securedata.key bs=512 count=1 sudo chmod 400 /root/securedata.key sudo cryptsetup luksAddKey /dev/sdb /root/securedata.key
Then add this line to /etc/crypttab:
securedata UUID=YOUR-UUID /root/securedata.key luks,nofail
and this one to /etc/fstab:
/dev/mapper/securedata /srv/secure ext4 defaults,nofail 0 2
nofail lets the server finish booting even if the disk is missing. In our generator test this entry was added to cryptsetup.target, so it unlocks during boot. Understand the trade-off: the key file sits on the unencrypted system disk, so this protects the data disk if it is removed or replaced on its own, but not if someone has a copy of both disks.
Manage passphrases
- Add a passphrase (for a colleague, or a recovery passphrase kept offline):
sudo cryptsetup luksAddKey /dev/sdb. It asks for an existing passphrase first. - Test a passphrase without unlocking:
$ sudo cryptsetup open --test-passphrase -v /dev/sdb No usable token is available. Enter passphrase for /dev/sdb: Key slot 1 unlocked. Command successful.
A wrong passphrase givesNo key available with this passphrase.(three tries, then exit code 2). - Remove a passphrase:
sudo cryptsetup luksRemoveKey /dev/sdband type the passphrase to delete. Make sure another working passphrase remains.
Back up the LUKS header
According to the cryptsetup manual, “If the header of a LUKS volume gets damaged, all data is permanently lost unless you have a header backup.” Make one and store it off the server:
sudo cryptsetup luksHeaderBackup /dev/sdb --header-backup-file /root/sdb.luksheader
In our test the file was 16 MiB. Restore it with luksHeaderRestore if the header is ever damaged. Keep the backup as safe as the passphrase: it contains the key slots that existed when you made it.
Only one disk? Use an encrypted container file
If your server has a single disk, you can still keep sensitive data encrypted in a LUKS container file:
sudo truncate -s 20G /srv/vault.img sudo cryptsetup luksFormat /srv/vault.img sudo cryptsetup open /srv/vault.img vault sudo mkfs.ext4 /dev/mapper/vault
When the device is a file, the cryptsetup manual says it “tries to allocate a loopback device and map it into this file”, so you mount /dev/mapper/vault exactly like a disk.
Full disk encryption of the system disk
The system disk can only be encrypted conveniently when you install Ubuntu. According to Ubuntu’s installation documentation, on the installer’s guided storage screen you select “Use an entire disk”, choose to set up the disk as an LVM group and to encrypt it with LUKS, then choose “a passphrase to be entered every time the system boots”.
On a server, plan how you will enter the passphrase at every boot, including unplanned reboots after kernel updates or power events:
- A VPS: the VNC console in Virtualizor (see how to access your VPS via VNC). To install Ubuntu yourself from an ISO, see manual OS installation in Virtualizor.
- A dedicated server: the IPMI console (see install an OS with Supermicro IPMI and virtual media).
- Remote unlock: Ubuntu 26.04 packages
dropbear-initramfs(an SSH server in early boot, where you type the passphrase) andclevis-lukswithclevis-initramfs(automatic unlock from a key server on your network, Tang). Test either on a non-production machine first.
Ubuntu’s security documentation lists TPM-backed full disk encryption for Ubuntu Desktop and Ubuntu Core; it needs TPM 2.0 and Secure Boot.
Related: encrypt swap with dm-crypt and crypttab, partition and mount a new disk, encrypt single files with GnuPG and back up a Linux server.
Official documentation: cryptsetup(8), crypttab(5), Ubuntu full disk encryption and installer storage options.