[SOLVED] luks-lvm boots without asking for password

Archlinuxomane · 2019-01-20 19:56:38

Hi, I somehow managed to get my luks-lvm configuration to boot without asking for the passphrase.
Here is my "# blkid":

/dev/nvme0n1p1: LABEL="boot" UUID="d94cbfaa-0e2e-4f76-be8b-e4f99c2e7b6b" TYPE="ext4" PARTUUID="989c897a-abd6-4eea-8c7e-71ac457ec4b1"
/dev/nvme0n1p2: UUID="B21E1AFD1E1AB9F5" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="91e72dc7-1be4-4b6b-8beb-7c5cac60a459"
/dev/nvme0n1p3: UUID="79a0339a-99aa-4910-a3fe-971b1ef5b96f" TYPE="crypto_LUKS" PARTLABEL="Linux LVM" PARTUUID="73db2206-3271-4081-9eb1-6f41e8136956"
/dev/mapper/cryptroot: UUID="UILSxd-hU1s-lPBU-yzeh-cVzF-KP8d-A2pEBP" TYPE="LVM2_member"
/dev/mapper/luks-swap: UUID="904da2a9-d7e0-4457-beb3-8417f4cbf3ad" TYPE="swap"
/dev/mapper/luks-rootlv: UUID="5ef57e24-9bc6-4969-b563-4484e3d0d62c" TYPE="ext4"
/dev/mapper/luks-home: UUID="a11a2110-bb44-4062-958c-1867f3a7ebff" TYPE="ext4"
/dev/nvme0n1: PTUUID="fcc5ef9e-27e1-4b34-be8c-cf973f9c7e67" PTTYPE="gpt"

/dev/sda1: LABEL="System-reserviert" UUID="CAB625EBB625D929" TYPE="ntfs" PARTUUID="0d9d8db5-bdac-19e2-ac72-806e6f6e6963"
/dev/sda2: LABEL="Win7" UUID="98E4337EE4335E26" TYPE="ntfs" PARTUUID="0d9d8db6-bdac-19e2-ac72-806e6f6e6963"
/dev/sda3: UUID="04D2597BD2597242" TYPE="ntfs" PARTUUID="fa04183e-1856-4d1c-b7dd-50b2288babd1"
/dev/sda4: LABEL="Daten" UUID="BCB82F1CB82ED4A4" TYPE="ntfs" PARTUUID="0d9d8db7-bdac-19e2-ac72-806e6f6e6963"
/dev/sda5: UUID="1834-4A6A" TYPE="vfat" PARTUUID="f7fffbdc-b9c1-4a05-a2fa-0091a0fa3384"
/dev/sda6: LABEL="root" UUID="17ab55bc-aa05-4f62-bff1-21e47959cd40" SEC_TYPE="ext2" TYPE="ext3" PARTLABEL="root" PARTUUID="71cbb3ef-9c27-4e7f-8e98-ddb37199f624"
/dev/sda7: LABEL="home" UUID="97cf5cbd-496a-42e1-a079-98f040722234" TYPE="ext3" PARTLABEL="home" PARTUUID="cb7eebf4-8937-486b-ad4f-e984bb679c05"
/dev/sdb1: LABEL="quellen" UUID="7389a6cf-1f11-4a85-b0f1-9333a0917b29" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="e8900690-01"
/dev/sdb2: LABEL="swap" UUID="5a2e81dc-9acd-447d-a227-c25ffcd4b77d" TYPE="swap" PARTUUID="e8900690-02"

and here is my "# mount":

/dev/mapper/luks-rootlv on / type ext4 (rw,noatime)
/dev/nvme0n1p1 on /boot type ext4 (rw,noatime)
/dev/mapper/luks-home on /home type ext4 (rw,noatime)
/dev/sda5 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=12308844k,nr_inodes=3077211,mode=755)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=3701)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=2464268k,mode=700,uid=1000,gid=1000)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

I'm currently transferring my install from my hdd to a new ssd by reinstalling the OS's parallel, so there a couple of extra partitions.

How is it possible that my encrypted luks-lvm can be read without the passprase? I didn't add any keyfile or anything, my crypttab is empty

Last edited by Archlinuxomane (2019-01-22 17:50:11)

jasonwryan · 2019-01-20 20:00:01

Perhaps if you told us how you actually set it up, ie., the command that you used...

Moving to NC.

Archlinuxomane · 2019-01-20 20:08:31

I pretty much followed the wiki https://wiki.archlinux.org/index.php/Dm … VM_on_LUKS
The only thing I changed is creating a separate /boot (ext4) and /boot/efi partition (fat) because my mainboard can't boot from a ssd, so the efi-partition had to be on the hdd

frostschutz · 2019-01-20 20:38:44

cryptsetup luksDump?

uptime?

Archlinuxomane · 2019-01-21 07:35:27

luksDump

LUKS header information for /dev/nvme0n1p3

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha256
Payload offset:	4096
MK bits:       	256
MK digest:     	xxx
MK salt:       	xxx
MK iterations: 	xxx
UUID:          	79a0339a-99aa-4910-a3fe-971b1ef5b96f

Key Slot 0: ENABLED
	Iterations:         	xxx
	Salt:               	xxx
	Key material offset:	xxx
	AF stripes:            	4000
Key Slot 1: ENABLED
	Iterations:         	xxx
	Salt:               	xxx
	Key material offset:	xxx
	AF stripes:            	4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

uptime

 08:36:26 up 10 min,  5 users,  load average: 0,20, 0,28, 0,19

I can't recall adding a second key. I had some problems setting up the boot environment, had to resetup /boot and reinstall grub to get all OS's to work, maybe I screwed something up there.
I'm just wondering how something like this is even possible...

frostschutz · 2019-01-21 10:56:14

What is your mkinitcpio configuration like, any custom or modified hooks, ...? Booted using which parameters, cat /proc/mdstat?

The reason I asked for uptime is because - you do have an unencrypted swap partition there, so instead of actually rebooting, you could have been hibernating and waking up instead, without ever losing access to the LUKS containement. However with a 10 minute uptime this theory seems to be wrong.

That leaves your LUKS with two keyslots. At the very least you should know what they are. You can test:

# cryptsetup -v luksOpen --test-passphrase /dev/xyz
Enter passphrase for /dev/xyz: <my first password>
Key slot 0 unlocked.
Command successful.

# cryptsetup -v luksOpen --test-passphrase /dev/xyz
Enter passphrase for /dev/xyz: <my second password>
Key slot 1 unlocked.
Command successful.

With -v --test-passphrase it will tell you which keyslot it would be using for the unlock.

Also try empty key (simply hit enter) just to make sure it refuses invalid pass.

Now if your password is slot 0 and you can't find another key for slot 1, there's a chance both slots may actually be the same passphrase. You can specify which keyslot should be tested explicitely:

# cryptsetup -v luksOpen --test-passphrase --key-slot 1 /dev/xyz
Enter passphrase for /dev/xyz: <my first password>
No key available with this passphrase.
Enter passphrase for /dev/xyz: <my second password>
Key slot 1 unlocked.
Command successful.

So it will only accept whichever is the valid key for this slot only (and in my case it's different but in your case might be the same passphrase twice).

If you absolutely cannot find a valid key for either of those slots, you can use luksKillSlot to remove it. (DANGEROUS OPTION, luksAddKey a 3rd passphrase first, killing the last one would lose you all data)

# cryptsetup -v luksAddKey /dev/xyz # just in case something to fall back on
Enter any existing passphrase: <my second passphrase>
Key slot 1 unlocked.
Enter new passphrase for key slot: <a new third passphrase>
Verify passphrase: <a new third passphrase>
Key slot 2 created.
Command successful.

# cryptsetup -v luksKillSlot /dev/xyz 0
Keyslot 0 is selected for deletion.
Enter any remaining passphrase: <my second passphrase>
Key slot 1 unlocked.
Key slot 0 removed.
Command successful.

None of this would solve your issue but then at least you would know for sure which passes this LUKS header will be accepting. It's not a good idea to have keyslots and no idea where they came from. Actually that may be reason enough to re-install everything from scratch. If someone managed to add a bogus key, they might also have obtained your master key and even if you luksChangeKey all your passwords, it will not be effective anymore. Same if you had an empty or otherwise insecure key.

And if whatever is unlocking your LUKS container without you knowing, if still able to unlock after changing keys, that'd be really weird then.

systemd has a way of remembering passphrases, but to my knowledge, it does not survive reboots. It's just a way to avoid re-entering the same passphrase again if it has already been used once during boot, so multiple LUKS containers that all unlock with the same pass are possible. But you don't get this with the 'encrypt' hook.

Last edited by frostschutz (2019-01-21 11:13:20)

Archlinuxomane · 2019-01-21 18:25:32

frostschutz wrote:

...

Thanks for your response!
I added the "lvm2" and "encrypt" hook and changed nothing else in my mkinitcpio.conf:

HOOKS=(base udev autodetect modconf block consolefont keymap keyboard encrypt lvm2 filesystems fsck)

I tested the keyslots, my passphrase only works for slot 0, both do not accept emtpy/wrong passphrases. I then added a new passphrase and deleted the two existing ones, which resulted in "no key available with this passphrase. Invalid keyfile. Reverting to passphrase. A password is required to access the cryptroot volume: Enter passphrase for /dev/xyz" upon booting. The prompt accepted my new passphrase. I then added the old passphrase back, which gave me the same prompt.
Seems the passphrase for keyslot 1, which I don't know, is somehow passed on to unlock my disk...
Very strange behaviour indeed, I wonder how I managed that - I'm going to reinstall now.

P.S.: The swap partition is for second linux I've installed, which is not enrypted at all. mdstat doesn't exist on my system, from searching for it I think it's only used for raid-setups, which I don't use.

/edit: however I screwed up my config, I'm marking the thread as solved

Last edited by Archlinuxomane (2019-01-22 17:45:16)

Arch Linux

#1 2019-01-20 19:56:38

[SOLVED] luks-lvm boots without asking for password

#2 2019-01-20 20:00:01

Re: [SOLVED] luks-lvm boots without asking for password

#3 2019-01-20 20:08:31

Re: [SOLVED] luks-lvm boots without asking for password

#4 2019-01-20 20:38:44

Re: [SOLVED] luks-lvm boots without asking for password

#5 2019-01-21 07:35:27

Re: [SOLVED] luks-lvm boots without asking for password

#6 2019-01-21 10:56:14

Re: [SOLVED] luks-lvm boots without asking for password

#7 2019-01-21 18:25:32

Re: [SOLVED] luks-lvm boots without asking for password

Board footer