Encrypt a disk with LUKS and cryptsetup

LUKS (Linux Unified Key Setup) encrypts a whole disk at block level: without the passphrase, the data is unreadable, even if the disk is stolen. The standard tool is cryptsetup. This guide shows how to encrypt a volume with LUKS2, manage several passphrases, back up the header (vital), and unlock at boot via /etc/crypttab or a network server (NBDE). For intermediate to advanced administrators, on Debian, Ubuntu or RHEL. Commands tested on AlmaLinux 10 (cryptsetup 2.8.1).

What you will learn

• Encrypt a volume with cryptsetup luksFormat (LUKS2)
• Open, format and mount the decrypted volume
• Manage passphrases and back up the header
• Unlock at boot with crypttab, and automatically with Clevis/Tang

Prerequisites

• A Linux server with sudo and the cryptsetup package
• A dedicated disk, partition or container file (encryption overwrites its content)
• Know how to identify a disk and mount it

Certification scope

LUKS encryption is not listed in the published objectives of the RHCSA EX200 nor in those of the LFCS. It is Red Hat's Security hardening documentation that covers LUKS and network unlocking (NBDE, Clevis/Tang): a hardening skill, expected on any server that stores sensitive data.

LUKS1 or LUKS2

Since cryptsetup 2.1, the default format is LUKS2, and it is the one to use. It brings a redundant header (stored twice, so more resistant to corruption) and Argon2id key derivation, designed to resist GPU cracking, where LUKS1 is limited to PBKDF2. LUKS2 also carries up to 32 key slots against 8 for LUKS1.

Encrypt a volume

The order never changes: format, open, create the file system on the mapping, mount. The file system always goes on /dev/mapper/..., never on the raw disk.

1. Format the volume as LUKS2. The operation asks for a confirmation (YES) and the passphrase.

   sudo cryptsetup luksFormat --type luks2 /dev/sdX

   The defaults are safe and confirmed by luksDump below: aes-xts-plain64 cipher, 512-bit key (that is AES-256, the XTS key being doubled), Argon2id derivation.

   The confirmation is case sensitive: the command asks Are you sure? (Type 'yes' in capital letters):, and a lowercase yes answer gives Operation aborted. without formatting anything. Only YES goes on.

   A passphrase that is too short is refused, and the message is misleading

   cryptsetup is built with PWQUALITY on RHEL and AlmaLinux, which cryptsetup --version confirms in its list of flags. It therefore applies the pwquality policy to your passphrase, and refuses those that are too short:

   Password quality check failed:
    The password is shorter than 8 characters

   The exit code is 2, and the message does not say where the constraint comes from: the reader thinks of a device problem. The required length is not hard-coded in cryptsetup, it is the minlen of /etc/security/pwquality.conf (8 on an AlmaLinux 10 with no particular configuration). A PAM hardening applied on the machine therefore also changes this requirement.

2. Inspect the header to check the format.

   sudo cryptsetup luksDump /dev/sdX

   Version:        2
   Keyslots:
     0: luks2
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
        PBKDF:      argon2id

3. Open the volume: it appears under /dev/mapper/.

   sudo cryptsetup open /dev/sdX coffre

4. Create the file system and mount the mapping.

   sudo mkfs.ext4 /dev/mapper/coffre
   sudo mkdir -p /mnt/coffre
   sudo mount /dev/mapper/coffre /mnt/coffre

To close the volume after unmounting: sudo umount /mnt/coffre && sudo cryptsetup close coffre. The data becomes unreadable again without the passphrase.

Encrypt a container file (no dedicated disk)

No free disk? Encrypt a file: cryptsetup handles it through an internal loop device.

sudo dd if=/dev/zero of=/srv/coffre.img bs=1M count=1024 status=none
sudo cryptsetup luksFormat --type luks2 /srv/coffre.img
sudo cryptsetup open /srv/coffre.img coffre

Manage passphrases

LUKS2 stores up to 32 independent passphrases in key slots: handy to give personal access to several administrators, then revoke one of them without changing the others.

sudo cryptsetup luksAddKey    /dev/sdX        # add a passphrase (a valid passphrase is asked)
sudo cryptsetup luksChangeKey /dev/sdX        # replace a passphrase
sudo cryptsetup luksRemoveKey /dev/sdX        # remove the passphrase typed
sudo cryptsetup luksKillSlot  /dev/sdX 2      # remove slot number 2 (another passphrase required)
sudo cryptsetup luksDump      /dev/sdX        # see the used slots

For automated unlocking, you can enrol a key file instead of a passphrase:

sudo dd if=/dev/urandom of=/root/luks.key bs=512 count=4
sudo chmod 0400 /root/luks.key
sudo cryptsetup luksAddKey /dev/sdX /root/luks.key

Back up the header (vital)

The LUKS header holds the encrypted keys: if it is corrupted, all data is lost, even with the right passphrase. An accidental write on the start of the disk (an unfortunate mkfs) is enough. Back it up offline:

sudo cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /secours/header.img

On LUKS2, this file is 16 MiB (16,777,216 bytes measured). Restore: cryptsetup luksHeaderRestore.

A header backup is as sensitive as the data

The header backup, combined with a passphrase valid at the time of the backup, makes it possible to decrypt the data, even if that passphrase has been removed since. Store it encrypted and offline; a luksRemoveKey does not protect against an old backup.

Unlock at boot: /etc/crypttab

For an encrypted volume to be available at boot, declare it in /etc/crypttab, which creates the /dev/mapper/ mapping, then mount that mapping via /etc/fstab (never the raw disk).

Get the UUID of the encrypted volume, then add the line (four fields: name, device, key, options):

sudo cryptsetup luksUUID /dev/sdX

/etc/crypttab

coffre UUID=5cda3d09-88cd-4c5e-941f-347749dd8025 none luks

The none key asks for the passphrase interactively at boot; replace it with a key file path for unlocking without typing. The /etc/fstab side then mounts the mapping:

/etc/fstab

/dev/mapper/coffre /mnt/coffre ext4 defaults,nofail 0 2

After a change, regenerate the initramfs so that unlocking works early at boot:

Debian / Ubuntu

sudo update-initramfs -u

RHEL / AlmaLinux

sudo dracut --force

Encrypted swap

Swap can write secrets in clear text. A crypttab entry with an ephemeral key encrypts it with a key thrown away at every reboot: cryptswap /dev/sdY /dev/urandom swap,cipher=aes-xts-plain64,size=256. Then reference /dev/mapper/cryptswap in fstab. Incompatible with hibernation. See the swap guide.

Automatic network unlocking (NBDE)

Typing a passphrase at every boot is impractical on a fleet of servers. NBDE (Network-Bound Disk Encryption) unlocks a volume automatically as long as the machine reaches a Tang server on the network, without ever sending the key. The client is Clevis, the server Tang; the state is stored in the LUKS2 header.

On the server, Tang is enabled as a service:

sudo systemctl enable tangd.socket --now

On the machine to encrypt, bind the volume to Tang. At the next boot, it will open by itself if it reaches the server:

sudo clevis luks bind -d /dev/sdX tang '{"url":"http://tang.interne.lan"}'
sudo clevis luks list -d /dev/sdX

Variant without network: bind the volume to the machine's TPM2 chip (clevis luks bind -d /dev/sdX tpm2 '{"pcr_ids":"7"}'). You can even require Tang AND TPM2 at the same time via the sss pin. NBDE security rests on the fact that an attacker needs both the physical disk and access to the network of the Tang server.

Reference procedure to validate on your fleet

The Clevis/Tang binding and the boot integration (clevis-luks, clevis-dracut/clevis-initramfs, tpm2-tools packages) depend on the distribution and need a working Tang server. Run it first on test machines.

Performance and TRIM

With the AES-NI acceleration present on every modern CPU, the cost of encryption is negligible compared with the speed of a disk. Measure it on your hardware:

cryptsetup benchmark

By default, TRIM/discard is disabled on encrypted volumes. Enabling it (cryptsetup open --allow-discards or the discard option in crypttab) improves the performance and lifetime of an SSD, but reveals at the physical level which blocks are used (file system type, space used). On a sensitive system, leave it disabled; enable it knowingly.

Traps to avoid

Encryption adds a layer you no longer see once the volume is open, and that is precisely what makes its mistakes costly: most of them only show up when you need the data.

• Header lost = total loss: back it up offline, it is non-negotiable.
• LUKS protects at rest only: once the volume is unlocked and mounted, files are in clear text for any authorised process. LUKS protects against disk theft, not against access to the running system.
• File system on the wrong device: always mkfs on /dev/mapper/..., never on the raw encrypted disk (that would destroy the header).
• Block versus file: LUKS encrypts the whole volume (ideal for disk, partition, swap). To encrypt a subfolder synced to a cloud, a per-file tool such as gocryptfs is better suited. Avoid eCryptfs, deprecated.
• Encrypted /boot and GRUB: an old GRUB does not handle Argon2id; for an encrypted root, validate the bootloader / version pair on your distribution.

Troubleshooting

cryptsetup messages are short but precise, and its exit code completes them: 2 for a refused passphrase, 5 for a mapping already open. Note both before touching the header.

Symptom	Likely cause	Fix
No key available with this passphrase.	Wrong passphrase or wrong slot	Try another passphrase, check luksDump
Volume not unlocked at boot	crypttab/initramfs not regenerated	Fix crypttab, update-initramfs/dracut
Device coffre already exists.	Mapping already open	cryptsetup close coffre before reopening
Unreadable data after an incident	Corrupted header	cryptsetup luksHeaderRestore from the backup
Slow opening	Argon2id uses RAM/CPU	Normal (anti brute force); adjust --pbkdf-memory at creation

Swipe to see more

Recommended hardware

To strengthen authentication beyond the passphrase, a YubiKey 5C NFC brings a hardware second factor (FIDO2) and can be used to unlock an encrypted volume, in addition to LUKS.

Amazon affiliate link. Buying through this link supports the site at no extra cost to you.

Put it into practice

Theory proves nothing until the volume has been encrypted, closed, then reopened after a reboot. This lab puts you on a VM with a blank disk: you run the full format, open, mkfs, mount, crypttab cycle, and the validation checks the real state of the machine after reboot, not the commands you typed.

Guided lab Practice

Learn how to do it

Encrypt a disk with LUKS

$ dsoxlab run l2-luks-encryption

Environment: VM·Duration: ~30 min

How it is checked: the state of the system is checked after a reboot, not the command you typed.

First time? What DSOXLab is and how to install it

DSOXLab is the command line that prepares a disposable environment (an isolated shell or a VM), runs the lab scenario, then checks the real state of the system and computes a score. Nothing is installed or broken on your workstation.

It needs Python 3.11 or later, uv or pipx, and git. The installation guide details these prerequisites; on Windows, or on a Mac without Python, use the appliance instead.

This lab starts virtual machines: it also needs ansible-playbook, a hypervisor (KVM or Incus), Terraform and hardware virtualization (/dev/kvm), which inside a VirtualBox VM means nested virtualization. The first time, dsoxlab start l2-luks-encryption checks all of it before creating the machines. Prepare your machine for vm labs.

Install the CLI and add the catalogue, once:

uv tool install dsoxlab   # or: pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training

Before you run the lab, check:

• DSOXLab installed
• catalogue available
• compatible environment (isolated shell or VM)

To check, nothing is probed from this page: run dsoxlab doctor. Read the diagnosis

Run this lab, then validate your work:

dsoxlab run l2-luks-encryption
dsoxlab check l2-luks-encryption

See every lab: dsoxlab list-labs. Track your progress: dsoxlab progress. The full dsoxlab guide covers scoring and the pitfalls.

Key points

• LUKS2 is the default format (Argon2id, redundant header, 32 slots): use it.
• The order is format → open → mkfs on the mapping → mount → close.
• The defaults are safe: aes-xts-plain64, 512-bit key (AES-256), Argon2id.
• Back up the header (luksHeaderBackup, 16 MiB) offline: losing it = total loss.
• Unlocking at boot via /etc/crypttab (by UUID) + fstab + initramfs; automatic with Clevis/Tang (NBDE) or TPM2.
• LUKS protects at rest: once mounted, the data is in clear text for the system.

Knowledge check

Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →