How to Completely Disable the ‘systemd-cryptsetup’ Service in Ubuntu Server

In Ubuntu Server and other modern Linux distributions, systemd-cryptsetup.service (and its associated generator) is a specialized systemd component responsible for automatically unlocking encrypted block devices during the boot sequence using configurations defined in /etc/crypttab. While essential for standard full-disk encryption (FDE) deployments (like LUKS) that require a passphrase prompt or a local keyfile, it introduces severe complications in strict, zero-trust cloud environments or headless servers that rely on external key management systems (KMS) or network-bound disk encryption (NBDE) protocols like Tang/Clevis. In these environments, attempting to parse a local crypttab file automatically can cause the boot process to hang indefinitely waiting for an interactive prompt that will never arrive.

This guide explains how to completely disable the systemd-cryptsetup infrastructure in Ubuntu Server, enforcing absolute manual or external orchestration control over the decryption of block devices.

Stop and Mask the systemd-cryptsetup Infrastructure

Because systemd-cryptsetup operates via generators during the early boot phase (initramfs) and as instantiated services (e.g., [email protected]), a simple disable command is fundamentally ineffective. To guarantee the init system is physically prevented from attempting to unlock volumes via crypttab under any circumstances, we must explicitly mask the target and the generator.

1. Log into your Ubuntu Server via SSH using an account with sudo privileges.
2. Disable the master cryptsetup target to remove it from the systemd boot dependencies:

   sudo systemctl disable cryptsetup.target

3. For absolute certainty, explicitly mask the target. This symlinks the unit file to /dev/null, creating a hard cryptographic block against it being invoked during the startup sequence:

   sudo systemctl mask cryptsetup.target

4. Additionally, if you need to prevent the generator from parsing /etc/crypttab entirely (e.g., to prevent initramfs hangs), you must mask the generator binary itself. (Warning: Only perform this if you are absolutely certain you are managing decryption manually or via NBDE later in the boot process):

   sudo ln -s /dev/null /etc/systemd/system-generators/systemd-cryptsetup-generator

5. Update the initramfs to ensure these changes are reflected in the early boot environment:

   sudo update-initramfs -u -k all

Verify the Service Lockdown

By masking cryptsetup.target and its generator, you guarantee that systemd will completely bypass the automatic decryption of LUKS volumes defined in crypttab, leaving the unlocking logic entirely to your external orchestration, KMS integration, or manual administrative intervention.

To verify the lockdown is successful, attempt to start the target manually:

sudo systemctl start cryptsetup.target

Systemd will return a fatal error stating that the unit is masked (e.g., Failed to start cryptsetup.target: Unit cryptsetup.target is masked). You have successfully neutralized the automated systemd decryption infrastructure, hardening your server’s state logic and ensuring compliance with strict, externally managed cryptographic deployment pipelines.