🚨 Security Error Guide: LUKS 'No key available with this passphrase'

Overview

LUKS (Linux Unified Key Setup) is the standard for full-disk and volume encryption on Linux. To open an encrypted device, a supplied passphrase or key file must match the key material stored in one of the device’s key slots. When nothing matches, cryptsetup refuses to unlock and the volume stays inaccessible. This is a security control working as designed — but it also fires when a passphrase is wrong, a key slot was removed, or the LUKS header is damaged.

The literal failure from cryptsetup luksOpen (or open) is:

No key available with this passphrase.

At boot, the same condition looks like a repeated prompt or a systemd cryptsetup failure:

cryptsetup: cryptdata: set up successfully
Please enter passphrase for disk data (cryptdata): ...
No key available with this passphrase.
Enter passphrase for /dev/nvme0n1p3 (cryptdata): 

And a corrupt or absent header produces a different but related error:

Device /dev/nvme0n1p3 is not a valid LUKS device.

The distinction matters: “No key available” means the header is intact but no slot matched the input; “not a valid LUKS device” means the header itself is unreadable.

Symptoms

• cryptsetup open returns No key available with this passphrase for a passphrase you believe is correct.
• Boot hangs at the disk passphrase prompt and retries indefinitely.
• A key file that used to work now fails, or works on one host but not another.
• cryptsetup luksDump shows fewer active key slots than expected, or errors out entirely.

sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -A1 'Keyslots:'

Keyslots:
  0: luks2

sudo cryptsetup open /dev/nvme0n1p3 cryptdata

Enter passphrase for /dev/nvme0n1p3: 
No key available with this passphrase.

Common Root Causes

1. Wrong passphrase or keyboard-layout mismatch

The most common cause: a typo, caps lock, or a non-US keymap at the initramfs prompt that differs from the layout used when the passphrase was set.

sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -c 'luks2'
# header is fine; the input simply doesn't match a slot

2. The key slot holding that passphrase was removed

Someone ran luksKillSlot or luksRemoveKey, deleting the slot that stored the passphrase you’re using.

sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -E '^\s+[0-7]: luks2'

  1: luks2

Only slot 1 remains; the passphrase for slot 0 no longer opens the device.

3. Missing or wrong key file / keyscript

/etc/crypttab references a key file that is missing, has wrong permissions, or was regenerated, so automated unlock fails and it falls back to a prompt.

sudo cat /etc/crypttab
sudo ls -l /etc/luks/keys/data.key

cryptdata UUID=... /etc/luks/keys/data.key luks
ls: cannot access '/etc/luks/keys/data.key': No such file or directory

4. Damaged LUKS header

A truncated dd, a partial overwrite, or a filesystem tool run against the wrong device corrupts the header, so no slot can be read.

sudo cryptsetup isLuks -v /dev/nvme0n1p3

Device /dev/nvme0n1p3 is not a valid LUKS device.
Command failed with code -1 (wrong or missing parameters).

5. Opening the wrong device or partition

The passphrase is correct, but it’s being applied to the wrong disk/partition (e.g., the raw disk instead of the LUKS partition, or a cloned volume with a different header).

lsblk -o NAME,FSTYPE,UUID | grep crypto_LUKS

6. LUKS2 with a memory-hard KDF on a low-RAM environment

A LUKS2 header using Argon2id can fail to derive the key in a constrained initramfs/rescue environment with too little memory, presenting as an unlock failure.

Diagnostic Workflow

Step 1: Confirm the device is really LUKS and the header is intact

sudo cryptsetup isLuks -v /dev/nvme0n1p3 && echo "valid LUKS"
sudo cryptsetup luksDump /dev/nvme0n1p3

If luksDump prints the header and key slots, the header is fine and the problem is the key/passphrase. If it errors, treat it as header corruption (Step 5).

Step 2: Enumerate active key slots

sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -E 'luks2|Keyslot'

Note how many slots are active. If the slot you expect is gone, someone removed it.

Step 3: Test each known passphrase against a specific slot

sudo cryptsetup open --test-passphrase --key-slot 0 /dev/nvme0n1p3 && echo "slot 0 matches"
sudo cryptsetup open --test-passphrase /dev/nvme0n1p3 && echo "some slot matches"

--test-passphrase verifies without mapping the device, so you can confirm which passphrase/slot works before unlocking.

Step 4: Check the crypttab key file path and permissions

sudo cat /etc/crypttab
sudo cryptsetup open --key-file /etc/luks/keys/data.key /dev/nvme0n1p3 cryptdata

If the file is missing or the wrong one, restore the correct key file (mode 0400, root-owned).

Step 5: Inspect and, if needed, restore the header from backup

Never write to the device blindly. Work from a header backup you made earlier:

sudo cryptsetup luksHeaderRestore /dev/nvme0n1p3 --header-backup-file /root/luks-header-p3.img
sudo cryptsetup luksDump /dev/nvme0n1p3

Step 6: Add a recovery passphrase once you are in

After opening with any working slot, add a fresh passphrase to a free slot:

sudo cryptsetup luksAddKey /dev/nvme0n1p3

Example Root Cause Analysis

A data volume on a rebuilt server stops unlocking at boot with No key available with this passphrase, even though the operator is certain the passphrase is right. The header looks healthy:

sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -E '^\s+[0-7]: luks2'

  1: luks2

Only slot 1 is active. Testing the operator’s passphrase against slots shows it matches nothing:

sudo cryptsetup open --test-passphrase /dev/nvme0n1p3

No key available with this passphrase.

Reviewing change history reveals that a prior hardening pass ran luksRemoveKey to rotate credentials and deleted slot 0 (the operator’s passphrase) but the new slot-1 passphrase was stored in the team vault. The current passphrase simply isn’t in any slot.

Fix: retrieve the slot-1 passphrase from the vault, open the device, then add the operator’s passphrase back to a free slot so both work:

sudo cryptsetup open /dev/nvme0n1p3 cryptdata   # using the vault passphrase
sudo cryptsetup luksAddKey /dev/nvme0n1p3        # add the operator passphrase to slot 0
sudo cryptsetup luksDump /dev/nvme0n1p3 | grep luks2

  0: luks2
  1: luks2

The volume opens and both credentials are valid again — without ever risking the encrypted data.

Prevention Best Practices

• Back up the LUKS header off-box the moment a device is created: cryptsetup luksHeaderBackup <dev> --header-backup-file <file>; a lost header means unrecoverable data.
• Keep at least two independent key slots (a human passphrase and a stored recovery key) so removing or losing one never locks you out.
• Store recovery passphrases and key files in a vault, and document which slot maps to which credential.
• Use --test-passphrase before scripting any luksKillSlot/luksRemoveKey, and always verify the target device path to avoid operating on the wrong disk.
• Set key-file permissions to 0400 root-owned, and keep /etc/crypttab paths in sync when rotating keys.
• Rehearse recovery on a throwaway volume so the header-restore and add-key steps are familiar before a real incident.

Quick Command Reference

# Confirm it's LUKS and dump the header/slots
sudo cryptsetup isLuks -v /dev/nvme0n1p3
sudo cryptsetup luksDump /dev/nvme0n1p3

# Test a passphrase without mapping the device
sudo cryptsetup open --test-passphrase /dev/nvme0n1p3
sudo cryptsetup open --test-passphrase --key-slot 0 /dev/nvme0n1p3

# Open with a key file
sudo cryptsetup open --key-file /etc/luks/keys/data.key /dev/nvme0n1p3 cryptdata

# Back up / restore the header (do this proactively!)
sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file hdr.img
sudo cryptsetup luksHeaderRestore /dev/nvme0n1p3 --header-backup-file hdr.img

# Add a recovery passphrase to a free slot
sudo cryptsetup luksAddKey /dev/nvme0n1p3

Conclusion

No key available with this passphrase means the LUKS header is intact but no key slot matched what you supplied — it is the encryption doing its job. Diagnose before you destroy anything:

1. A wrong passphrase or an initramfs keymap mismatch.
2. The key slot that held your passphrase was removed during rotation.
3. A missing or wrong crypttab key file falling back to a prompt.
4. A damaged header (not a valid LUKS device) needing a header restore.
5. Operating on the wrong device or a clone with a different header.

Confirm the header with luksDump, test passphrases with --test-passphrase, restore from a header backup if needed, and always keep a second key slot and an off-box header backup so a LUKS lockout never becomes data loss.