Remove One LUKS Key Slot Safely with cryptsetup

cryptsetup luksKillSlot wipes one passphrase from a LUKS device while a different, known passphrase stays valid for recovery. The examples use cryptsetup 2.7.0 from the installed cryptsetup-bin package, version 2:2.7.0-1ubuntu4.2.

Allow about fifteen minutes, plus the time to make and check a header backup. You need root privileges, the LUKS device or detached header, the slot number to remove, and a different passphrase that still opens the container. This operation changes LUKS metadata. It does not ask you to recreate the filesystem, but a mistake can lock you out permanently.

1. Identify the device and the slot

First establish exactly which LUKS header you intend to change. Substitute a real device path for the placeholder, and run the inspection command as root:

$ sudo cryptsetup luksDump /dev/mapper/REPLACE_WITH_LUKS_DEVICE

Read the output and record the key slot number whose passphrase should go. A slot number is metadata, not a filesystem path. Do not guess it from the order in which people remember adding keys. If the header is stored separately, inspect it with the same --header value that you will use for the removal:

$ sudo cryptsetup --header /path/to/REPLACE_WITH_DETACHED_HEADER \
    luksDump /dev/REPLACE_WITH_DATA_DEVICE

Checkpoint: you should have one written-down device or header pair, one target slot, and one remaining passphrase that you have tested or can test independently. If any of those is unclear, stop here.

2. Make a header backup

A key slot cannot be recreated from the passphrase alone after it has been wiped. Make a binary backup before changing metadata, and store it somewhere protected from loss and unauthorised access:

$ sudo cryptsetup luksHeaderBackup /dev/REPLACE_WITH_LUKS_DEVICE \
    --header-backup-file /var/tmp/REPLACE_WITH_LUKS_HEADER_BACKUP

For a detached header, give the data device and add the header option:

$ sudo cryptsetup --header /path/to/REPLACE_WITH_DETACHED_HEADER \
    luksHeaderBackup /dev/REPLACE_WITH_DATA_DEVICE \
    --header-backup-file /var/tmp/REPLACE_WITH_LUKS_HEADER_BACKUP

Protect the backup as carefully as the passphrases. It contains the header and keyslot area, so anyone who obtains it may be able to attack the encrypted volume offline. Keep the file until you have confirmed the change and your recovery arrangements.

3. Remove the selected slot interactively

Run luksKillSlot with the device and the exact slot number:

$ sudo cryptsetup luksKillSlot /dev/REPLACE_WITH_LUKS_DEVICE REPLACE_WITH_SLOT_NUMBER
Enter passphrase for key slot to be deleted: REPLACE_WITH_TARGET_PASSPHRASE
Enter any remaining passphrase: REPLACE_WITH_REMAINING_PASSPHRASE

The command needs a remaining valid passphrase to authorise the operation. The first prompt identifies the slot being removed; the second proves that another usable key remains. The prompt wording may vary with the installed build and terminal, so use the slot number and your records rather than relying on prompt text alone.

Warning: this is the irreversible point. Removing the last remaining passphrase makes the LUKS container permanently inaccessible. The command normally asks for interactive confirmation in that case, but do not treat that question as a safety net. If the command reports success, the selected key slot has been wiped from the LUKS header.

Checkpoint: do not continue to another storage task until the command has returned to the shell without an error. If it fails, read the error and leave the metadata alone while you investigate.

4. Use a key file only when its boundaries are clear

For automation, --key-file reads the passphrase from a file. It is still an elevated, destructive operation, and the file itself needs suitable permissions and a secure lifetime:

$ sudo cryptsetup --key-file /path/to/REPLACE_WITH_REMAINING_KEYFILE \
    luksKillSlot /dev/REPLACE_WITH_LUKS_DEVICE REPLACE_WITH_SLOT_NUMBER

The key file supplies the passphrase used to authorise the command. It does not select the slot; the final positional argument does that. If the file contains a fixed-size record or trailing data, --keyfile-offset skips bytes at the beginning and --keyfile-size limits how many bytes are read. The size option can be useful for excluding a trailing newline.

Warning: be particularly careful with standard input. Supplying --key-file -, or reading the passphrase from stdin in the relevant form, implicitly enables batch mode. That suppresses the warning when the last remaining passphrase is removed. Never pipe an unreviewed secret into a command that can destroy the last access path.

5. Handle detached headers and timeouts deliberately

If the LUKS header is in a separate device or file, --header must point to that metadata location. The positional device still identifies the data device. Keep the option on every related command so that inspection, backup and removal address the same header.

Interactive passphrase input waits forever by default. On a maintenance script or boot-sensitive workflow, --timeout REPLACE_WITH_SECONDS limits terminal prompts. It has no effect when --key-file is used. A timeout is not a rollback: if the operation has already succeeded, timing out a later prompt cannot restore the slot.

Do not add --disable-locks just because a command is inconvenient. It is valid only for LUKS2 and is intended for restricted environments where normal metadata locking cannot work. Disabling locks can allow competing processes to change the same metadata, so use it only when the environment and concurrent access are understood.

6. Verify the resulting header

Inspect the header again and confirm that the intended slot is no longer active:

$ sudo cryptsetup luksDump /dev/REPLACE_WITH_LUKS_DEVICE

The slot should now be shown as inactive or otherwise absent from the active keyslot entries, depending on the LUKS format and the output of this cryptsetup version. Do not expect the old passphrase to work. Test the remaining passphrase through your normal opening procedure, preferably during a planned maintenance window and with the header backup available.

Recovery: if the wrong slot was removed, the supported path is to restore the matching header backup, after first stopping writes and checking that the backup belongs to this exact volume. Header restoration is itself a destructive metadata operation. Do not restore an old backup over a live volume casually, because it can discard later keyslot or header changes. If you have no usable backup and no remaining passphrase, cryptsetup cannot manufacture access to the encrypted data.

Done means