Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debian 12 Non root device Unlocking issues with Tang #457

Open
bigops opened this issue Mar 10, 2024 · 5 comments
Open

Debian 12 Non root device Unlocking issues with Tang #457

bigops opened this issue Mar 10, 2024 · 5 comments
Labels

Comments

@bigops
Copy link

bigops commented Mar 10, 2024

In Debian 12 non root devices are not unlocked with just /etc/crypttab entries (with _netdev). With only crypttab the system silently fails to unlock and does not wait for the password. Adding the mapped devices in /etc/fstab with the _netdev option successfuly gives the password prompt and unlocks with Tang. The behavior was different in Debian 11 where crypttab entry alone will unlock the device

@sarroutbi sarroutbi added the bug label Mar 10, 2024
@sarroutbi
Copy link
Collaborator

Hello @bigops : is this issue related to the new release, clevis-20?

@bigops
Copy link
Author

bigops commented Mar 11, 2024

The version as per dpkg is 19-2

@cbiedl
Copy link

cbiedl commented Jun 22, 2024

Debian maintainer here, also promising to look into this mailbox more often.
@bigops Sorry to hear about these issues. Although you've found a solution, I'd still like to investigate, so can you describe your setup a bit more in detail?
If I understand correctly you have two encrypted block devices. One holds the root filesystem and is unlocked as expected. The second is something different that however should be unlocked during boot. Important question: Should that unlocking happen in the initrd stage, or later, as part of the regular crypttab handling?
In the first case, adding ",initramfs" to the crypttab should help, see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000648#20 and /usr/share/doc/clevis-initramfs/README.Debian

@sarroutbi sarroutbi changed the title Debain 12 Non root device Unlocking issues with Tang Debian 12 Non root device Unlocking issues with Tang Sep 23, 2024
@Z10N0110
Copy link

I think this is because the remote-cryptsetup.target is not enabled. I ran into the same problem on debian 12 today and then manual enable the unit resolved it, not touched /etc/fstab as you do. Not sure this is a clevis bug, more like related to debian team or systemd.

This unit is not enabled by default and seems not processed right when systemd-cryptsetup-generator processing /etc/crypttab, which i think the systemd should enable remote-cryptsetup.target automatically when read the _netdev option, or maybe the unit should enabled by default.

Detail

Current Debian Info:

root@debian-12-1:~# cat /etc/debian_version
12.7
root@debian-12-1:~# uname -a
Linux debian-12-1 6.10.11+bpo-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.10.11-1~bpo12+1 (2024-10-03) x86_64 GNU/Linux

Defined two entries in /etc/crypttab, sdb1 with _netdev:

root@debian-12-1:~# cat /etc/crypttab
# <target name>	<source device>		<key file>	<options>
#
sdb1 UUID=b2ffe45e-08b7-48df-a1b6-41160b9968e7 none luks,_netdev
sdc1 UUID=8938da1d-8a42-4780-ab00-474a570ea70c none luks

run systemctl daemon-reload to generate systemd-cryptsetup@[TARGET].service files, and then you can tell the difference that how the _netdev option affects, as it's described in systemd's crypttab(5) man page:

sdb1:

root@debian-12-1:~# systemctl cat [email protected]
# /run/systemd/generator/[email protected]
# Automatically generated by systemd-cryptsetup-generator

[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:[email protected](8)
SourcePath=/etc/crypttab
DefaultDependencies=no
IgnoreOnIsolate=true
After=cryptsetup-pre.target systemd-udevd-kernel.socket
Before=blockdev@dev-mapper-%i.target
Wants=blockdev@dev-mapper-%i.target
After=remote-fs-pre.target
Conflicts=umount.target
Before=remote-cryptsetup.target
BindsTo=dev-disk-by\x2duuid-b2ffe45e\x2d08b7\x2d48df\x2da1b6\x2d41160b9968e7.device
After=dev-disk-by\x2duuid-b2ffe45e\x2d08b7\x2d48df\x2da1b6\x2d41160b9968e7.device
Before=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
KeyringMode=shared
OOMScoreAdjust=500
ExecStart=/lib/systemd/systemd-cryptsetup attach 'sdb1' '/dev/disk/by-uuid/b2ffe45e-08b7-48df-a1b6-41160b9968e7' 'none' 'luks,_netdev'
ExecStop=/lib/systemd/systemd-cryptsetup detach 'sdb1'

sdc1:

root@debian-12-1:~# systemctl cat [email protected]
# /run/systemd/generator/[email protected]
# Automatically generated by systemd-cryptsetup-generator

[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:[email protected](8)
SourcePath=/etc/crypttab
DefaultDependencies=no
IgnoreOnIsolate=true
After=cryptsetup-pre.target systemd-udevd-kernel.socket
Before=blockdev@dev-mapper-%i.target
Wants=blockdev@dev-mapper-%i.target
Conflicts=umount.target
Before=cryptsetup.target
BindsTo=dev-disk-by\x2duuid-8938da1d\x2d8a42\x2d4780\x2dab00\x2d474a570ea70c.device
After=dev-disk-by\x2duuid-8938da1d\x2d8a42\x2d4780\x2dab00\x2d474a570ea70c.device
Before=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
KeyringMode=shared
OOMScoreAdjust=500
ExecStart=/lib/systemd/systemd-cryptsetup attach 'sdc1' '/dev/disk/by-uuid/8938da1d-8a42-4780-ab00-474a570ea70c' 'none' 'luks'
ExecStop=/lib/systemd/systemd-cryptsetup detach 'sdc1'

With the remote-cryptsetup.target disabled, [email protected] will be "inactive" after startup:

root@debian-12-1:~# systemctl status remote-cryptsetup.target
○ remote-cryptsetup.target - Remote Encrypted Volumes
     Loaded: loaded (/lib/systemd/system/remote-cryptsetup.target; disabled; preset: enabled)
     Active: inactive (dead)
       Docs: man:systemd.special(7)
root@debian-12-1:~# reboot

root@debian-12-1:~# uptime
 10:38:18 up 1 min,  1 user,  load average: 0.49, 0.17, 0.06
root@debian-12-1:~# systemctl status [email protected][email protected] - Cryptography Setup for sdb1
     Loaded: loaded (/etc/crypttab; generated)
     Active: inactive (dead)
       Docs: man:crypttab(5)
             man:systemd-cryptsetup-generator(8)
             man:[email protected](8)
root@debian-12-1:~# systemctl status [email protected][email protected] - Cryptography Setup for sdc1
     Loaded: loaded (/etc/crypttab; generated)
     Active: active (exited) since Wed 2024-10-30 10:36:51 UTC; 1min 34s ago
       Docs: man:crypttab(5)
             man:systemd-cryptsetup-generator(8)
             man:[email protected](8)
    Process: 333 ExecStart=/lib/systemd/systemd-cryptsetup attach sdc1 /dev/disk/by-uuid/8938da1d-8a42-4780-ab00-474a570ea70c none luks (code=exited, status=0/SUCCESS)
   Main PID: 333 (code=exited, status=0/SUCCESS)
        CPU: 2.327s

Oct 30 10:36:45 debian-12-1 systemd[1]: Starting [email protected] - Cryptography Setup for sdc1...
Oct 30 10:36:47 debian-12-1 systemd-cryptsetup[333]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/8938da1d-8a42-4780-ab00-474a570ea70c.
Oct 30 10:36:51 debian-12-1 systemd[1]: Finished [email protected] - Cryptography Setup for sdc1.

@Z10N0110
Copy link

By the way, as the 7c17448 message described, clevis maintainer no more recommend to add the _netdev option in crypttab, and prefer to use clevis in initramfs withdracut tool. Which means you should deal the network requirement by yourself in initramfs if your clevis pin is only tang.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants