557 lines
26 KiB
XML
557 lines
26 KiB
XML
<?xml version="1.0"?>
|
|
<!--*-nxml-*-->
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
<!--
|
|
SPDX-License-Identifier: LGPL-2.1-or-later
|
|
|
|
This is based on crypttab(5) from Fedora's initscripts package, which in
|
|
turn is based on Debian's version.
|
|
|
|
The Red Hat version has been written by Miloslav Trmac <mitr@redhat.com>.
|
|
-->
|
|
<refentry id="crypttab" conditional='HAVE_LIBCRYPTSETUP' xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
|
|
<refentryinfo>
|
|
<title>crypttab</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>crypttab</refentrytitle>
|
|
<manvolnum>5</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>crypttab</refname>
|
|
<refpurpose>Configuration for encrypted block devices</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<para><filename>/etc/crypttab</filename></para>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>The <filename>/etc/crypttab</filename> file describes
|
|
encrypted block devices that are set up during system boot.</para>
|
|
|
|
<para>Empty lines and lines starting with the <literal>#</literal>
|
|
character are ignored. Each of the remaining lines describes one
|
|
encrypted block device. Fields are delimited by white space.</para>
|
|
|
|
<para>Each line is in the form<programlisting><replaceable>volume-name</replaceable> <replaceable>encrypted-device</replaceable> <replaceable>key-file</replaceable> <replaceable>options</replaceable></programlisting>
|
|
The first two fields are mandatory, the remaining two are
|
|
optional.</para>
|
|
|
|
<para>Setting up encrypted block devices using this file supports
|
|
three encryption modes: LUKS, TrueCrypt and plain. See
|
|
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
for more information about each mode. When no mode is specified in
|
|
the options field and the block device contains a LUKS signature,
|
|
it is opened as a LUKS device; otherwise, it is assumed to be in
|
|
raw dm-crypt (plain mode) format.</para>
|
|
|
|
<para>The first field contains the name of the resulting encrypted volume; its block device is set up
|
|
below <filename>/dev/mapper/</filename>.</para>
|
|
|
|
<para>The second field contains a path to the underlying block
|
|
device or file, or a specification of a block device via
|
|
<literal>UUID=</literal> followed by the UUID.</para>
|
|
|
|
<para>The third field specifies an absolute path to a file with the encryption key. Optionally,
|
|
the path may be followed by <literal>:</literal> and an fstab device specification (e.g. starting with
|
|
<literal>LABEL=</literal> or similar); in which case the path is taken relative to the device file system
|
|
root. If the field is not present or is <literal>none</literal> or <literal>-</literal>, a key file
|
|
named after the volume to unlock (i.e. the first column of the line), suffixed with
|
|
<filename>.key</filename> is automatically loaded from the <filename>/etc/cryptsetup-keys.d/</filename>
|
|
and <filename>/run/cryptsetup-keys.d/</filename> directories, if present. Otherwise, the password has to
|
|
be manually entered during system boot. For swap encryption, <filename>/dev/urandom</filename> may be
|
|
used as key file.</para>
|
|
|
|
<para>The fourth field, if present, is a comma-delimited list of
|
|
options. The following options are recognized:</para>
|
|
|
|
<variablelist class='fstab-options'>
|
|
|
|
<varlistentry>
|
|
<term><option>cipher=</option></term>
|
|
|
|
<listitem><para>Specifies the cipher to use. See <citerefentry
|
|
project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
for possible values and the default value of this option. A cipher with unpredictable IV values, such
|
|
as <literal>aes-cbc-essiv:sha256</literal>, is recommended. Embedded commas in the cipher
|
|
specification need to be escaped by preceding them with a backslash, see example below.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>discard</option></term>
|
|
|
|
<listitem><para>Allow discard requests to be passed through the encrypted block
|
|
device. This improves performance on SSD storage but has security implications.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>hash=</option></term>
|
|
|
|
<listitem><para>Specifies the hash to use for password
|
|
hashing. See
|
|
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
for possible values and the default value of this
|
|
option.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>header=</option></term>
|
|
|
|
<listitem><para>Use a detached (separated) metadata device or
|
|
file where the LUKS header is stored. This option is only
|
|
relevant for LUKS devices. See
|
|
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
for possible values and the default value of this
|
|
option.</para>
|
|
|
|
<para>Optionally, the path may be followed by <literal>:</literal> and an fstab device specification
|
|
(e.g. starting with <literal>UUID=</literal> or similar); in which case, the path is relative to the
|
|
device file system root. The device gets mounted automatically for LUKS device activation duration only.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>keyfile-offset=</option></term>
|
|
|
|
<listitem><para>Specifies the number of bytes to skip at the
|
|
start of the key file. See
|
|
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
for possible values and the default value of this
|
|
option.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>keyfile-size=</option></term>
|
|
|
|
<listitem><para>Specifies the maximum number of bytes to read
|
|
from the key file. See
|
|
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
for possible values and the default value of this option. This
|
|
option is ignored in plain encryption mode, as the key file
|
|
size is then given by the key size.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>keyfile-erase</option></term>
|
|
|
|
<listitem><para>If enabled, the specified key file is erased after the volume is activated or when
|
|
activation fails. This is in particular useful when the key file is only acquired transiently before
|
|
activation (e.g. via a file in <filename>/run/</filename>, generated by a service running before
|
|
activation), and shall be removed after use. Defaults to off.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>key-slot=</option></term>
|
|
|
|
<listitem><para>Specifies the key slot to compare the
|
|
passphrase or key against. If the key slot does not match the
|
|
given passphrase or key, but another would, the setup of the
|
|
device will fail regardless. This option implies
|
|
<option>luks</option>. See
|
|
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
for possible values. The default is to try all key slots in
|
|
sequential order.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>keyfile-timeout=</option></term>
|
|
|
|
<listitem><para> Specifies the timeout for the device on
|
|
which the key file resides and falls back to a password if
|
|
it could not be mounted. See
|
|
<citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
for key files on external devices.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>luks</option></term>
|
|
|
|
<listitem><para>Force LUKS mode. When this mode is used, the
|
|
following options are ignored since they are provided by the
|
|
LUKS header on the device: <option>cipher=</option>,
|
|
<option>hash=</option>,
|
|
<option>size=</option>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>bitlk</option></term>
|
|
|
|
<listitem><para>Decrypt Bitlocker drive. Encryption parameters
|
|
are deduced by cryptsetup from Bitlocker header.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>_netdev</option></term>
|
|
|
|
<listitem><para>Marks this cryptsetup device as requiring network. It will be
|
|
started after the network is available, similarly to
|
|
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
units marked with <option>_netdev</option>. The service unit to set up this device
|
|
will be ordered between <filename>remote-fs-pre.target</filename> and
|
|
<filename>remote-cryptsetup.target</filename>, instead of
|
|
<filename>cryptsetup-pre.target</filename> and
|
|
<filename>cryptsetup.target</filename>.</para>
|
|
|
|
<para>Hint: if this device is used for a mount point that is specified in
|
|
<citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
the <option>_netdev</option> option should also be used for the mount
|
|
point. Otherwise, a dependency loop might be created where the mount point
|
|
will be pulled in by <filename>local-fs.target</filename>, while the
|
|
service to configure the network is usually only started <emphasis>after</emphasis>
|
|
the local file system has been mounted.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>noauto</option></term>
|
|
|
|
<listitem><para>This device will not be added to <filename>cryptsetup.target</filename>.
|
|
This means that it will not be automatically unlocked on boot, unless something else pulls
|
|
it in. In particular, if the device is used for a mount point, it'll be unlocked
|
|
automatically during boot, unless the mount point itself is also disabled with
|
|
<option>noauto</option>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>nofail</option></term>
|
|
|
|
<listitem><para>This device will not be a hard dependency of
|
|
<filename>cryptsetup.target</filename>. It'll still be pulled in and started, but the system
|
|
will not wait for the device to show up and be unlocked, and boot will not fail if this is
|
|
unsuccessful. Note that other units that depend on the unlocked device may still fail. In
|
|
particular, if the device is used for a mount point, the mount point itself also needs to
|
|
have the <option>nofail</option> option, or the boot will fail if the device is not unlocked
|
|
successfully.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>offset=</option></term>
|
|
|
|
<listitem><para>Start offset in the backend device, in 512-byte sectors. This
|
|
option is only relevant for plain devices.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>plain</option></term>
|
|
|
|
<listitem><para>Force plain encryption mode.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>read-only</option></term><term><option>readonly</option></term>
|
|
|
|
<listitem><para>Set up the encrypted block device in read-only
|
|
mode.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>same-cpu-crypt</option></term>
|
|
|
|
<listitem><para>Perform encryption using the same cpu that IO was submitted on. The default is to use
|
|
an unbound workqueue so that encryption work is automatically balanced between available CPUs.</para>
|
|
|
|
<para>This requires kernel 4.0 or newer.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>submit-from-crypt-cpus</option></term>
|
|
|
|
<listitem><para>Disable offloading writes to a separate thread after encryption. There are some
|
|
situations where offloading write requests from the encryption threads to a dedicated thread degrades
|
|
performance significantly. The default is to offload write requests to a dedicated thread because it
|
|
benefits the CFQ scheduler to have writes submitted using the same context.</para>
|
|
|
|
<para>This requires kernel 4.0 or newer.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>skip=</option></term>
|
|
|
|
<listitem><para>How many 512-byte sectors of the encrypted data to skip at the
|
|
beginning. This is different from the <option>offset=</option> option with respect
|
|
to the sector numbers used in initialization vector (IV) calculation. Using
|
|
<option>offset=</option> will shift the IV calculation by the same negative
|
|
amount. Hence, if <option>offset=<replaceable>n</replaceable></option> is given,
|
|
sector <replaceable>n</replaceable> will get a sector number of 0 for the IV
|
|
calculation. Using <option>skip=</option> causes sector
|
|
<replaceable>n</replaceable> to also be the first sector of the mapped device, but
|
|
with its number for IV generation being <replaceable>n</replaceable>.</para>
|
|
|
|
<para>This option is only relevant for plain devices.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>size=</option></term>
|
|
|
|
<listitem><para>Specifies the key size in bits. See
|
|
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
for possible values and the default value of this
|
|
option.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>sector-size=</option></term>
|
|
|
|
<listitem><para>Specifies the sector size in bytes. See
|
|
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
for possible values and the default value of this
|
|
option.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>swap</option></term>
|
|
|
|
<listitem><para>The encrypted block device will be used as a
|
|
swap device, and will be formatted accordingly after setting
|
|
up the encrypted block device, with
|
|
<citerefentry project='man-pages'><refentrytitle>mkswap</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
|
|
This option implies <option>plain</option>.</para>
|
|
|
|
<para>WARNING: Using the <option>swap</option> option will
|
|
destroy the contents of the named partition during every boot,
|
|
so make sure the underlying block device is specified
|
|
correctly.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>tcrypt</option></term>
|
|
|
|
<listitem><para>Use TrueCrypt encryption mode. When this mode
|
|
is used, the following options are ignored since they are
|
|
provided by the TrueCrypt header on the device or do not
|
|
apply:
|
|
<option>cipher=</option>,
|
|
<option>hash=</option>,
|
|
<option>keyfile-offset=</option>,
|
|
<option>keyfile-size=</option>,
|
|
<option>size=</option>.</para>
|
|
|
|
<para>When this mode is used, the passphrase is read from the
|
|
key file given in the third field. Only the first line of this
|
|
file is read, excluding the new line character.</para>
|
|
|
|
<para>Note that the TrueCrypt format uses both passphrase and
|
|
key files to derive a password for the volume. Therefore, the
|
|
passphrase and all key files need to be provided. Use
|
|
<option>tcrypt-keyfile=</option> to provide the absolute path
|
|
to all key files. When using an empty passphrase in
|
|
combination with one or more key files, use
|
|
<literal>/dev/null</literal> as the password file in the third
|
|
field.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>tcrypt-hidden</option></term>
|
|
|
|
<listitem><para>Use the hidden TrueCrypt volume. This option
|
|
implies <option>tcrypt</option>.</para>
|
|
|
|
<para>This will map the hidden volume that is inside of the
|
|
volume provided in the second field. Please note that there is
|
|
no protection for the hidden volume if the outer volume is
|
|
mounted instead. See
|
|
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
for more information on this limitation.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>tcrypt-keyfile=</option></term>
|
|
|
|
<listitem><para>Specifies the absolute path to a key file to
|
|
use for a TrueCrypt volume. This implies
|
|
<option>tcrypt</option> and can be used more than once to
|
|
provide several key files.</para>
|
|
|
|
<para>See the entry for <option>tcrypt</option> on the
|
|
behavior of the passphrase and key files when using TrueCrypt
|
|
encryption mode.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>tcrypt-system</option></term>
|
|
|
|
<listitem><para>Use TrueCrypt in system encryption mode. This
|
|
option implies <option>tcrypt</option>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>tcrypt-veracrypt</option></term>
|
|
|
|
<listitem><para>Check for a VeraCrypt volume. VeraCrypt is a fork of
|
|
TrueCrypt that is mostly compatible, but uses different, stronger key
|
|
derivation algorithms that cannot be detected without this flag.
|
|
Enabling this option could substantially slow down unlocking, because
|
|
VeraCrypt's key derivation takes much longer than TrueCrypt's. This
|
|
option implies <option>tcrypt</option>.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>timeout=</option></term>
|
|
|
|
<listitem><para>Specifies the timeout for querying for a
|
|
password. If no unit is specified, seconds is used. Supported
|
|
units are s, ms, us, min, h, d. A timeout of 0 waits
|
|
indefinitely (which is the default).</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>tmp=</option></term>
|
|
|
|
<listitem><para>The encrypted block device will be prepared for using it as
|
|
<filename>/tmp/</filename>; it will be formatted using <citerefentry
|
|
project='man-pages'><refentrytitle>mkfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Takes
|
|
a file system type as argument, such as <literal>ext4</literal>, <literal>xfs</literal> or
|
|
<literal>btrfs</literal>. If no argument is specified defaults to <literal>ext4</literal>. This
|
|
option implies <option>plain</option>.</para>
|
|
|
|
<para>WARNING: Using the <option>tmp</option> option will destroy the contents of the named partition
|
|
during every boot, so make sure the underlying block device is specified correctly.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>tries=</option></term>
|
|
|
|
<listitem><para>Specifies the maximum number of times the user
|
|
is queried for a password. The default is 3. If set to 0, the
|
|
user is queried for a password indefinitely.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>verify</option></term>
|
|
|
|
<listitem><para>If the encryption password is read from console, it has to be entered twice to
|
|
prevent typos.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>pkcs11-uri=</option></term>
|
|
|
|
<listitem><para>Takes a <ulink url="https://tools.ietf.org/html/rfc7512">RFC7512 PKCS#11 URI</ulink>
|
|
pointing to a private RSA key which is used to decrypt the key specified in the third column of the
|
|
line. This is useful for unlocking encrypted volumes through security tokens or smartcards. See below
|
|
for an example how to set up this mechanism for unlocking a LUKS volume with a YubiKey security
|
|
token. The specified URI can refer directly to a private RSA key stored on a token or alternatively
|
|
just to a slot or token, in which case a search for a suitable private RSA key will be performed. In
|
|
this case if multiple suitable objects are found the token is refused. The key configured in the
|
|
third column is passed as is to RSA decryption. The resulting decrypted key is then base64 encoded
|
|
before it is used to unlock the LUKS volume.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>try-empty-password=</option></term>
|
|
|
|
<listitem><para>Takes a boolean argument. If enabled, right before asking the user for a password it
|
|
is first attempted to unlock the volume with an empty password. This is useful for systems that are
|
|
initialized with an encrypted volume with only an empty password set, which shall be replaced with a
|
|
suitable password during first boot, but after activation.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>x-systemd.device-timeout=</option></term>
|
|
|
|
<listitem><para>Specifies how long systemd should wait for a device to show up
|
|
before giving up on the entry. The argument is a time in seconds or explicitly
|
|
specified units of
|
|
<literal>s</literal>,
|
|
<literal>min</literal>,
|
|
<literal>h</literal>,
|
|
<literal>ms</literal>.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>x-initrd.attach</option></term>
|
|
|
|
<listitem><para>Setup this encrypted block device in the initramfs, similarly to
|
|
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
units marked with <option>x-initrd.mount</option>.</para>
|
|
|
|
<para>Although it's not necessary to mark the mount entry for the root file system with
|
|
<option>x-initrd.mount</option>, <option>x-initrd.attach</option> is still recommended with
|
|
the encrypted block device containing the root file system as otherwise systemd will
|
|
attempt to detach the device during the regular system shutdown while it's still in
|
|
use. With this option the device will still be detached but later after the root file
|
|
system is unmounted.</para>
|
|
|
|
<para>All other encrypted block devices that contain file systems mounted in the initramfs
|
|
should use this option.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
<para>At early boot and when the system manager configuration is
|
|
reloaded, this file is translated into native systemd units by
|
|
<citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Examples</title>
|
|
<example>
|
|
<title>/etc/crypttab example</title>
|
|
<para>Set up four encrypted block devices. One using LUKS for normal storage, another one for usage as
|
|
a swap device and two TrueCrypt volumes. For the fourth device, the option string is interpreted as two
|
|
options <literal>cipher=xchacha12,aes-adiantum-plain64</literal>,
|
|
<literal>keyfile-timeout=10s</literal>.</para>
|
|
|
|
<programlisting>luks UUID=2505567a-9e27-4efe-a4d5-15ad146c258b
|
|
swap /dev/sda7 /dev/urandom swap
|
|
truecrypt /dev/sda2 /etc/container_password tcrypt
|
|
hidden /mnt/tc_hidden /dev/null tcrypt-hidden,tcrypt-keyfile=/etc/keyfile
|
|
external /dev/sda3 keyfile:LABEL=keydev keyfile-timeout=10s,cipher=xchacha12\,aes-adiantum-plain64
|
|
</programlisting>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Yubikey-based Volume Unlocking Example</title>
|
|
|
|
<para>The PKCS#11 logic allows hooking up any compatible security token that is capable of storing RSA
|
|
decryption keys. Here's an example how to set up a Yubikey security token for this purpose, using
|
|
<citerefentry project='debian'><refentrytitle>ykmap</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
from the yubikey-manager project:</para>
|
|
|
|
<programlisting><xi:include href="yubikey-crypttab.sh" parse="text" /></programlisting>
|
|
|
|
<para>A few notes on the above:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>We use RSA (and not ECC), since Yubikeys support PKCS#11 Decrypt() only for RSA keys</para></listitem>
|
|
<listitem><para>We use RSA2048, which is the longest key size current Yubikeys support</para></listitem>
|
|
<listitem><para>LUKS key size must be shorter than 2048bit due to RSA padding, hence we use 128 bytes</para></listitem>
|
|
<listitem><para>We use Yubikey key slot 9d, since that's apparently the keyslot to use for decryption purposes,
|
|
<ulink url="https://developers.yubico.com/PIV/Introduction/Certificate_slots.html">see
|
|
documentation</ulink>.</para></listitem>
|
|
</itemizedlist>
|
|
|
|
</example>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
<para>
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
|
<citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
|
<citerefentry project='man-pages'><refentrytitle>mkswap</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
|
<citerefentry project='man-pages'><refentrytitle>mke2fs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|