Safely Remove One Passphrase from a LUKS Device

You will remove one known passphrase from a LUKS container and confirm that another passphrase still opens it. Allow about fifteen minutes, plus the time needed to identify the correct device and key. You need the cryptsetup-bin package, the passphrase to remove, and a second working passphrase or another recovery method.

This guide uses cryptsetup 2.7.0 from Ubuntu package cryptsetup-bin 2:2.7.0-1ubuntu4.2. LUKS metadata changes are security-sensitive. A mistake in the device name or key choice can lock you out, and removing the last remaining passphrase makes the container permanently inaccessible.

1. Check the installed command

First confirm the binary and version. These are ordinary, read-only commands and do not need elevated privileges:

$ command -v cryptsetup
/usr/sbin/cryptsetup
$ cryptsetup --version
cryptsetup 2.7.0 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL
$ dpkg-query -W -f='${Package} ${Version}\n' cryptsetup-bin
cryptsetup-bin 2:2.7.0-1ubuntu4.2

The action has this shape:

$ sudo cryptsetup luksRemoveKey [options] DEVICE [KEYFILE]

With no key file argument, cryptsetup asks for the passphrase interactively. The command changes the LUKS header, so sudo is normally required for a block device. A detached header is a special case: pass --header HEADER_DEVICE_OR_FILE and use the data device as the final argument, as described in step 3.

2. Make the safety decision before changing anything

Do not start with the removal command. Record the exact device path and establish which passphrases should remain. For a mapped device, the name such as /dev/mapper/cryptdata is not the LUKS container path; identify the underlying LUKS device using your normal inventory or lsblk workflow.

Checkpoint: write down the device you intend to change, the passphrase you intend to remove, and the passphrase you will test afterwards. If you cannot name a second working passphrase or recovery route, stop. Removing the only passphrase is not a recoverable access change.

Never paste a real passphrase into shell history or put it directly in the command line. A key file is safer for repeatable administration, but protect it, use a short-lived path, and remove it after the operation. The key file contains the credential in plain text while it exists.

3. Remove a passphrase interactively

For a one-off change, let cryptsetup prompt for the passphrase to remove:

$ sudo cryptsetup luksRemoveKey /dev/disk/by-id/REPLACE_WITH_THE_LUKS_DEVICE

Enter the passphrase that should be removed when prompted. The command does not ask for the replacement passphrase. On success, it normally returns to the shell without a success message.

For a detached LUKS header, use the header location explicitly:

$ sudo cryptsetup luksRemoveKey --header /path/to/REPLACE_WITH_HEADER_FILE /path/to/REPLACE_WITH_DATA_DEVICE

Do not add --batch-mode casually. The manpage warns that batch mode suppresses confirmation questions, and stdin input can implicitly enable it. The command's --verify-passphrase option only verifies an interactively entered passphrase twice; it is not a second-person safety check and is ignored for key files or stdin.

4. Use a protected key file when automation requires it

If an approved maintenance process already supplies the passphrase from a file, pass that file with --key-file:

$ sudo cryptsetup luksRemoveKey --key-file /run/user/REPLACE_WITH_ID/old-passphrase.key /dev/disk/by-id/REPLACE_WITH_THE_LUKS_DEVICE

The file is read as the passphrase. A name of - reads from standard input and does not stop at newline characters. That mode is easy to misunderstand: stdin input implicitly enables batch mode, so no warning is given if the operation removes the last remaining passphrase.

Use --keyfile-offset BYTES when the passphrase starts at an offset in a larger file. Use --keyfile-size BYTES to limit how much is read, for example to exclude trailing data or a newline. The default is the whole file up to cryptsetup's compiled-in maximum, which can be inspected with cryptsetup --help. If the file is temporary, restrict its permissions before use and remove it immediately afterwards using your site's secure credential-handling procedure.

5. Verify the remaining passphrase

Do not treat a quiet return as proof that you selected the intended slot. Test the passphrase that must remain, without activating the volume:

$ sudo cryptsetup open --test-passphrase --key-file /path/to/REPLACE_WITH_REMAINING_KEYFILE /dev/disk/by-id/REPLACE_WITH_THE_LUKS_DEVICE
$ printf 'verification status: %s\n' "$?"
verification status: 0

For an interactive test, omit --key-file and let cryptsetup prompt. A status of zero means the supplied passphrase was accepted for the device. A non-zero status means it was not accepted or the device could not be checked; investigate the error rather than trying more destructive commands.

Now check that the removed passphrase is rejected, using a protected key file or an interactive prompt:

$ sudo cryptsetup open --test-passphrase --key-file /path/to/REPLACE_WITH_REMOVED_KEYFILE /dev/disk/by-id/REPLACE_WITH_THE_LUKS_DEVICE
$ printf 'removed-key test status: %s\n' "$?"
removed-key test status: 2

The exact non-zero status can vary with the failure and installed build, so the useful result is rejection, not a particular number. Do not use cryptsetup open without --test-passphrase for this check: that would create a device mapping and introduce a separate activation and cleanup task.

6. Recover when the result is not what you expected

If the removal command fails, leave the header unchanged and read the error. Check the device path, header option, key file permissions, key file offset and size, and whether the supplied passphrase is actually the one to remove. Retry only after those facts are clear.

If the command succeeds but the remaining passphrase is rejected, stop using the container and preserve any header backups and logs. Do not run luksFormat, luksErase or another key-removal command as an attempted repair. Those are different operations and can destroy the route to recovery. Consult the cryptsetup documentation and your backup procedure with the exact device and header details.