Cryptsetup non root

Only one device can be unlocked in the initramfs. Setting additional options that are supported by crypttab , e.

See crypttab for the syntax. You can use any of the persistent block device naming methods. Passwords entered during boot are cached in the kernel keyring by systemd-cryptsetup 8 , so if multiple devices can be unlocked with the same password this includes devices in crypttab that are unlocked after boot , then you will only need to input each password once.

Note: All of the rd. The rd. This is because the luks. Tip: rd. Tip: When using this parameter you can omit rd. Tip: The whole rd. Warning: If the type of file system is different than your root file system, you must include the kernel module for it in the initramfs. Warning: If the nofail option is specified, the password entry screen may disappear while typing the password.

For dm-crypt plain mode devices, the plain option must be explicitly set to force systemd-cryptsetup to recognize them. See systemd issue For more information, see systemd GPT partition automounting. Tip: Passwords entered in the password prompt are cached in the kernel keyring by systemd-cryptsetup 8 when using the sd-encrypt hook , this also includes passwords entered in the initramfs stage.

If a device in crypttab uses a previously entered password, the third parameter can be set to none and the cached password will be automatically used. Note: Keep in mind that the timeout option in crypttab only determines the amount of time allowed for entering the password of the encrypted device.

In addition, systemd also has a default timeout which determines the amount of time allowed for the device to be available defaulting to 90 seconds , which is independent of the password timer.

In consequence, even when the timeout option in crypttab is set to a value larger than 90 seconds or it is at its default value of 0, meaning unlimited time , systemd will still only wait a maximum of 90 seconds for the device to be unlocked. In order to change the time systemd will wait for a device to be available, the option x-systemd.

It is probably desired, then, that the amount of time of the timeout option in crypttab is equal to the amount of time of the x-systemd. Take care to apply the systemd workaround mentioned in crypttab in this case. Category : Data-at-rest encryption.

Hidden category: Pages or sections flagged with Template:Expansion. Always needed when encrypting the root partition, or a partition that needs to be mounted before root. This hook must be placed after the udev or systemd hook. Needed to make keyboards work in early userspace. Provides support for non-US keymaps for typing encryption passwords; it must come before the encrypt hook, otherwise you will need to enter your encryption password using the default US keymap.

For dm-crypt plain mode, the open action will not error out itself. For example LUKS mode could be stacked on the "plain1" mapper. Its header would then be encrypted inside "plain1" when that is closed.

Available for plain mode only is the option --shared. With it a single device can be segmented into different non-overlapping mappers. We do that in the next example, using a loopaes compatible cipher mode for "plain2" this time:. As the device tree shows both reside on the same level, i. It is possible to define addition keys for the LUKS partition.

A different key-slot could also be used to grant access to a partition to a user by issuing a second key and later revoking it again. Once an encrypted partition has been created, the initial keyslot 0 is created if no other was specified manually.

Additional keyslots are numbered from 1 to 7. Which keyslots are used can be seen by issuing. Where device is the block device containing the LUKS header. This and all the following commands in this section work on header backup files as well. Adding new keyslots is accomplished using cryptsetup with the luksAddKey action. For safety it will always, i. Otherwise a new passphrase will be prompted for twice. For using an existing keyfile to authorize the action, the --key-file or -d option followed by the "old" keyfile will try to unlock all available keyfile keyslots:.

If it is intended to use multiple keys and change or revoke them, the --key-slot or -S option may be used to specify the slot:.

For above warning it is good to know the key we want to keep is valid. An easy check is to unlock the device with the -v option, which will specify which slot it occupies:. If we had used the same passphrase for two keyslots, the first slot would be wiped now. Only executing it again would remove the second one.

To re-iterate the warning above: If the same passphrase had been used for key slots 1 and 6, both would be gone now. If the header of a LUKS encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much of a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition.

Damage may occur by your own fault while re-partitioning the disk later or by third-party programs misinterpreting the partition table. Therefore, having a backup of the header and storing it on another disk might be a good idea.

You can also back up the plain text header into ramfs and encrypt it with e. GPG before writing it to persistent storage:.

In order to evade restoring a wrong header, you can ensure it does work by using it as a remote --header first:. Now that all the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing the command. The header always resides at the beginning of the device and a backup can be performed without access to cryptsetup as well.

First you have to find out the payload offset of the crypted partition:. Now that you know the values, you can backup the header with a simple dd command:. This article or section needs expansion. The cryptsetup package features two options for re-encryption. Both can be used to convert an existing unencrypted file system to a LUKS encrypted one or permanently remove LUKS encryption from a device using --decrypt.

As its name suggests it can also be used to re-encrypt an existing LUKS encrypted device, though, re-encryption is not possible for a detached LUKS header or other encryption modes e.

One application of re-encryption may be to secure the data again after a passphrase or keyfile has been compromised and one cannot be certain that no copy of the LUKS header has been obtained. The following shows an example to encrypt an unencrypted file system partition and a re-encryption of an existing LUKS device. A LUKS encryption header is always stored at the beginning of the device. Since an existing file system will usually be allocated all partition sectors, the first step is to shrink it to make space for the LUKS header.

If the current file system occupies all the available space, we will have to shrink it at least that much. As a final step we extend the original ext4 file system to occupy all available space again, on the now encrypted partition:.

The file system is now ready to use. You may want to add it to your crypttab. In order to re-encrypt a device with its existing encryption options, they do not need to be specified:. Another use case is to re-encrypt LUKS devices which have non-current encryption options. Apart from above warning on specifying options correctly, the ability to change the LUKS header may also be limited by its size.

For example, if the device was initially encrypted using a CBC mode cipher and bit key-size, the LUKS header will be half the size of above mentioned sectors:. While it is possible to upgrade the encryption of such a device, it is currently only feasible in two steps.

First, re-encrypting with the same encryption options, but using the --reduce-device-size option to make further space for the larger LUKS header. Second, re-encypt the whole device again with the desired cipher. For this reason and the fact that a backup should be created in any case, creating a new, fresh encrypted device to restore into is always the faster option. The argument --type is required. If a storage device encrypted with dm-crypt is being cloned with a tool like dd to another larger device, the underlying dm-crypt device must be resized to use the whole space.

Next, expand the container file with the size of the data you want to add. After this, resize the encrypted part of the container to the new maximum size of the container file:. If the device was formatted with integrity support e. To fix this issue without wiping the device again, it can be formatted with the previous master key keeping the per-sector tags valid. A keyfile is a file whose data is used as the passphrase to unlock an encrypted volume.

That means if such a file is lost or changed, decrypting the volume may no longer be possible. There are many kinds of keyfiles.

Each type of keyfile used has benefits and disadvantages summarized below:. This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not add any security over entering a passphrase during the initial system start. If the file contains special characters such as a backslash, rather than escaping these, it is recommended to simply edit the key file directly entering or pasting the passphrase and then remove the trailing newline with a handy perl one-liner:.

Moving mouse and keyboard typing might help in this case. Read the crypttab 5 manpage for more information, for example options to use a different encryption algorithm than the default. If a key is stored on a vfat filesystem very common for removable media , chmod and chown will not work. The vfat filesystem and several others too does not support file permissions and ownership. As a workaround for some yet-to-be-fixed race condition in kernel, device-mapper or udev, cryptsetup currently runs udevsettle.

This leads to problems if you invoke cryptsetup as part of a udev rule. Therefore cryptsetup should be detached directly after invocation in this case, so that it runs asynchronously. The cryptsetup package ships with several keyscripts. The syntax is:. Passdev will wait for a given device to appear, mount it read-only, read the key, and unmount the device. The check option in crypttab allows one to configure checks to be run against the target device after cryptsetup has been invoked.

The default check blkid can check for any known filesystem type, as it uses blkid from util-linux. Please send us your checks, if you write new ones. If they are generally useful, we will include them in the package. Splashy support in cryptsetup is currently somehow limited. Splashy is known to freeze at the password dialog for encrypted non-root filesystems.