[opensuse] LUKS decryption password requested multiple times during boot in text mode

Philippe Andersson

25 May 2020 25 May '20

15:20

Hello List, We're putting in place LUKS-based filesystem encryption on our systems (GDPR and all that...). On workstations or laptops, where the boot process is graphical thanks to Plymouth, the decryption key is only requested once even when multiple filesystems are encrypted (provided they all use the same password, of course). On physical servers on the other hand, that we configure to boot in text mode (as we need to interact with them remotely over a virtual serial console), we get prompted for the decryption password once for every encrypted device -- which is far from optimal from a usability perspective. Is there any way to get in text mode a behaviour comparable to the one provided in graphical mode (single password prompt, no matter how many devices are encrypted)? TIA Cheers. Bye. Ph. A. -- *Philippe Andersson* Unix System Administrator IBA Particle Therapy | Tel: +32-10-475.983 Fax: +32-10-487.707 eMail: pan@iba-group.com http://www.iba-worldwide.com Disclaimer | Use of IBA e-communicationhttps://iba-worldwide.com/disclaimer The contents of this e-mail message and any attachments are intended solely for the recipient (s) named above. This communication is intended to be and to remain confidential and may be protected by intellectual property rights. Any use of the information contained herein (including but not limited to, total or partial reproduction, communication or distribution of any form) by persons other than the designated recipient(s) is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. Ion Beam Applications does not accept liability for any such errors. Thank you for your cooperation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Show replies by date

Adam Mizerski

25 May 25 May

17:25

W dniu 25.05.2020 o 17:20, Philippe Andersson pisze:

...

Hello List,

We're putting in place LUKS-based filesystem encryption on our systems (GDPR and all that...).

On workstations or laptops, where the boot process is graphical thanks to Plymouth, the decryption key is only requested once even when multiple filesystems are encrypted (provided they all use the same password, of course).

On physical servers on the other hand, that we configure to boot in text mode (as we need to interact with them remotely over a virtual serial console), we get prompted for the decryption password once for every encrypted device -- which is far from optimal from a usability perspective.

Is there any way to get in text mode a behaviour comparable to the one provided in graphical mode (single password prompt, no matter how many devices are encrypted)?

TIA

Cheers. Bye.

Ph. A.

I don't know your partitioning, but I use this: https://en.opensuse.org/SDB:Encrypted_root_file_system#Avoiding_to_type_the_... This instruction assumes that both "/" and "/boot" are encrypted and grub is asking for password. If your setup has encrypted only some partitions with critical data, you can something similar: - choose one encrypted partition that will be unlocked with password - use steps 1-4 to create keys for other partitions

Philippe Andersson

26 May 26 May

07:32

On 25/05/2020 19:25, Adam Mizerski wrote:

...

W dniu 25.05.2020 o 17:20, Philippe Andersson pisze:

...
Hello List,

We're putting in place LUKS-based filesystem encryption on our systems (GDPR and all that...).

On workstations or laptops, where the boot process is graphical thanks to Plymouth, the decryption key is only requested once even when multiple filesystems are encrypted (provided they all use the same password, of course).

On physical servers on the other hand, that we configure to boot in text mode (as we need to interact with them remotely over a virtual serial console), we get prompted for the decryption password once for every encrypted device -- which is far from optimal from a usability perspective.

Is there any way to get in text mode a behaviour comparable to the one provided in graphical mode (single password prompt, no matter how many devices are encrypted)?

TIA

Cheers. Bye.

Ph. A.

I don't know your partitioning, but I use this: https://en.opensuse.org/SDB:Encrypted_root_file_system#Avoiding_to_type_the_...

This instruction assumes that both "/" and "/boot" are encrypted and grub is asking for password.

If your setup has encrypted only some partitions with critical data, you can something similar: - choose one encrypted partition that will be unlocked with password - use steps 1-4 to create keys for other partitions

Hello Adam, Yes, I was already aware of this technique. But the idea of leaving the decryption key in a file on the server itself seemed far from optimal. It also means that it would get included in DRP images, and those are typically not encrypted at all. Ph. A. -- *Philippe Andersson* Unix System Administrator IBA Particle Therapy | Tel: +32-10-475.983 Fax: +32-10-487.707 eMail: pan@iba-group.com http://www.iba-worldwide.com Disclaimer | Use of IBA e-communicationhttps://iba-worldwide.com/disclaimer The contents of this e-mail message and any attachments are intended solely for the recipient (s) named above. This communication is intended to be and to remain confidential and may be protected by intellectual property rights. Any use of the information contained herein (including but not limited to, total or partial reproduction, communication or distribution of any form) by persons other than the designated recipient(s) is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. Ion Beam Applications does not accept liability for any such errors. Thank you for your cooperation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

08:06

On 26/05/2020 09.32, Philippe Andersson wrote:

...

On 25/05/2020 19:25, Adam Mizerski wrote:

...
W dniu 25.05.2020 o 17:20, Philippe Andersson pisze:

...

...
I don't know your partitioning, but I use this: https://en.opensuse.org/SDB:Encrypted_root_file_system#Avoiding_to_type_the_...

This instruction assumes that both "/" and "/boot" are encrypted and grub is asking for password.

If your setup has encrypted only some partitions with critical data, you can something similar: - choose one encrypted partition that will be unlocked with password - use steps 1-4 to create keys for other partitions

Hello Adam,

Yes, I was already aware of this technique. But the idea of leaving the decryption key in a file on the server itself seemed far from optimal.

But it would be on an encrypted partition.

...

It also means that it would get included in DRP images, and those are typically not encrypted at all.

Ah, that's a point. In that case, you could create another partition, very small, encrypted, out of the backup set, and containing the key file. But yes, if you can get the TW method to work on Leap, that would be better. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Adam Majer

08:54

On 5/26/20 9:32 AM, Philippe Andersson wrote:

...

Yes, I was already aware of this technique. But the idea of leaving the decryption key in a file on the server itself seemed far from optimal.

How so? Once your device is active, you can just dump the keys if you have root, dmsetup table --showkeys TBH, having a key in an ecrypted filesystem readable only by root is not much different.

...

It also means that it would get included in DRP images, and those are typically not encrypted at all.

If they are not encrypted, then your data is as safe as those images are. I don't understand how having a key on those images would then jeopardize security of your data. If unauthorized person grabs those unencrypted images, you lose, keyfile or no keyfile. But if you at least have backup of the keyfile, then if you forget your passphrase, at least you can gain access to your current drive without restore. - Adam -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

25 May 25 May

17:53

On 25/05/2020 17.20, Philippe Andersson wrote:

...

Hello List,

We're putting in place LUKS-based filesystem encryption on our systems (GDPR and all that...).

On workstations or laptops, where the boot process is graphical thanks to Plymouth, the decryption key is only requested once even when multiple filesystems are encrypted (provided they all use the same password, of course).

On physical servers on the other hand, that we configure to boot in text mode (as we need to interact with them remotely over a virtual serial console), we get prompted for the decryption password once for every encrypted device -- which is far from optimal from a usability perspective.

Is there any way to get in text mode a behaviour comparable to the one provided in graphical mode (single password prompt, no matter how many devices are encrypted)?

Yes. The procedure is to create a random key that is stored in a file in the first decrypted partition, and add that key to the other partitions. Example: dd iflag=fullblock if=/dev/random of=the_hoard_keyfile bs=512 count=8 cryptsetup luksAddKey /dev/sdd1 /home/cer/Keys/the_hoard_keyfile crypto_unmap cr_hoard2 cryptsetup luksOpen --key-file=/home/cer/Keys/the_hoard_keyfile /dev/sdd1 cr_hoard2 /etc/crypttab: cr_hoard /dev/disk/by-uuid/f1f26736... /home/cer/Keys/the_hoard_keyfile auto systemctl daemon-reload │····· AmonLanc:~ # systemctl start systemd-cryptsetup@cr_hoard2 -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Andrei Borzenkov

18:09

25.05.2020 18:20, Philippe Andersson пишет:

...

Hello List,

We're putting in place LUKS-based filesystem encryption on our systems (GDPR and all that...).

On workstations or laptops, where the boot process is graphical thanks to Plymouth, the decryption key is only requested once even when multiple filesystems are encrypted (provided they all use the same password, of course).

On physical servers on the other hand, that we configure to boot in text mode (as we need to interact with them remotely over a virtual serial console), we get prompted for the decryption password once for every encrypted device -- which is far from optimal from a usability perspective.

Is there any way to get in text mode a behaviour comparable to the one provided in graphical mode (single password prompt, no matter how many devices are encrypted)?

Everything is possible by writing suitable program. If you ask whether your specific distribution version used on your servers can do it without additional programming, you need to tell what you are using. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov

18:38

25.05.2020 21:09, Andrei Borzenkov пишет:

...

25.05.2020 18:20, Philippe Andersson пишет:

...
Hello List,

We're putting in place LUKS-based filesystem encryption on our systems (GDPR and all that...).

On workstations or laptops, where the boot process is graphical thanks to Plymouth, the decryption key is only requested once even when multiple filesystems are encrypted (provided they all use the same password, of course).

On physical servers on the other hand, that we configure to boot in text mode (as we need to interact with them remotely over a virtual serial console), we get prompted for the decryption password once for every encrypted device -- which is far from optimal from a usability perspective.

Is there any way to get in text mode a behaviour comparable to the one provided in graphical mode (single password prompt, no matter how many devices are encrypted)?

Everything is possible by writing suitable program. If you ask whether your specific distribution version used on your servers can do it without additional programming, you need to tell what you are using.

I briefly tried on TW without plymouth and password is cached by default, no special configuration needed. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

20:05

On 25/05/2020 20.38, Andrei Borzenkov wrote:

...

25.05.2020 21:09, Andrei Borzenkov пишет:

...
25.05.2020 18:20, Philippe Andersson пишет:

...
Hello List,

We're putting in place LUKS-based filesystem encryption on our systems (GDPR and all that...).

On workstations or laptops, where the boot process is graphical thanks to Plymouth, the decryption key is only requested once even when multiple filesystems are encrypted (provided they all use the same password, of course).

On physical servers on the other hand, that we configure to boot in text mode (as we need to interact with them remotely over a virtual serial console), we get prompted for the decryption password once for every encrypted device -- which is far from optimal from a usability perspective.

Is there any way to get in text mode a behaviour comparable to the one provided in graphical mode (single password prompt, no matter how many devices are encrypted)?

Everything is possible by writing suitable program. If you ask whether your specific distribution version used on your servers can do it without additional programming, you need to tell what you are using.

I briefly tried on TW without plymouth and password is cached by default, no special configuration needed.

That must be new :-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Philippe Andersson

26 May 26 May

07:50

On 25/05/2020 22:05, Carlos E. R. wrote:

...

On 25/05/2020 20.38, Andrei Borzenkov wrote:

...
25.05.2020 21:09, Andrei Borzenkov пишет:

...
25.05.2020 18:20, Philippe Andersson пишет:

...
Hello List,

We're putting in place LUKS-based filesystem encryption on our systems (GDPR and all that...).

On workstations or laptops, where the boot process is graphical thanks to Plymouth, the decryption key is only requested once even when multiple filesystems are encrypted (provided they all use the same password, of course).

On physical servers on the other hand, that we configure to boot in text mode (as we need to interact with them remotely over a virtual serial console), we get prompted for the decryption password once for every encrypted device -- which is far from optimal from a usability perspective.

Is there any way to get in text mode a behaviour comparable to the one provided in graphical mode (single password prompt, no matter how many devices are encrypted)?

Everything is possible by writing suitable program. If you ask whether your specific distribution version used on your servers can do it without additional programming, you need to tell what you are using.

I briefly tried on TW without plymouth and password is cached by default, no special configuration needed.

That must be new :-)

Thanks for the pointer -- I'll have a look at this new mechanism in TW. Ph. A. -- *Philippe Andersson* Unix System Administrator IBA Particle Therapy | Tel: +32-10-475.983 Fax: +32-10-487.707 eMail: pan@iba-group.com http://www.iba-worldwide.com Disclaimer | Use of IBA e-communicationhttps://iba-worldwide.com/disclaimer The contents of this e-mail message and any attachments are intended solely for the recipient (s) named above. This communication is intended to be and to remain confidential and may be protected by intellectual property rights. Any use of the information contained herein (including but not limited to, total or partial reproduction, communication or distribution of any form) by persons other than the designated recipient(s) is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. Ion Beam Applications does not accept liability for any such errors. Thank you for your cooperation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Philippe Andersson

07:36

On 25/05/2020 20:09, Andrei Borzenkov wrote:

...

25.05.2020 18:20, Philippe Andersson пишет:

...
Hello List,

We're putting in place LUKS-based filesystem encryption on our systems (GDPR and all that...).

On workstations or laptops, where the boot process is graphical thanks to Plymouth, the decryption key is only requested once even when multiple filesystems are encrypted (provided they all use the same password, of course).

On physical servers on the other hand, that we configure to boot in text mode (as we need to interact with them remotely over a virtual serial console), we get prompted for the decryption password once for every encrypted device -- which is far from optimal from a usability perspective.

Is there any way to get in text mode a behaviour comparable to the one provided in graphical mode (single password prompt, no matter how many devices are encrypted)?

Everything is possible by writing suitable program. If you ask whether your specific distribution version used on your servers can do it without additional programming, you need to tell what you are using.

Sorry Andrei, I should have said: openSUSE 15.1 and SLES 15. Ph. A. -- *Philippe Andersson* Unix System Administrator IBA Particle Therapy | Tel: +32-10-475.983 Fax: +32-10-487.707 eMail: pan@iba-group.com http://www.iba-worldwide.com Disclaimer | Use of IBA e-communicationhttps://iba-worldwide.com/disclaimer The contents of this e-mail message and any attachments are intended solely for the recipient (s) named above. This communication is intended to be and to remain confidential and may be protected by intellectual property rights. Any use of the information contained herein (including but not limited to, total or partial reproduction, communication or distribution of any form) by persons other than the designated recipient(s) is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. Ion Beam Applications does not accept liability for any such errors. Thank you for your cooperation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov

08:04

On Tue, May 26, 2020 at 10:36 AM Philippe Andersson wrote:

...

...
Sorry Andrei, I should have said: openSUSE 15.1 and SLES 15.

systemd has support for caching passwords since version 227. Leap 15.1 has systemd 234 so it should work as long as you use standard systemd mechanism for working with encrypted containers. That is what I tested in TW. I will check Leap this evening. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Philippe Andersson

08:17

On 26/05/2020 10:04, Andrei Borzenkov wrote:

...

On Tue, May 26, 2020 at 10:36 AM Philippe Andersson wrote:

...
...
Sorry Andrei, I should have said: openSUSE 15.1 and SLES 15.

systemd has support for caching passwords since version 227. My understanding was that this caching was done by Plymouth, as called by /usr/lib/dracut/modules.d/90crypt/crypt-lib.sh.

...

Leap 15.1 has systemd 234 so it should work as long as you use standard systemd mechanism for working with encrypted containers. That is what I tested in TW. I will check Leap this evening.

Thanks -- I'll setup a test VM to play with this as well. Ph. A. -- *Philippe Andersson* Unix System Administrator IBA Particle Therapy | Tel: +32-10-475.983 Fax: +32-10-487.707 eMail: pan@iba-group.com http://www.iba-worldwide.com Disclaimer | Use of IBA e-communicationhttps://iba-worldwide.com/disclaimer The contents of this e-mail message and any attachments are intended solely for the recipient (s) named above. This communication is intended to be and to remain confidential and may be protected by intellectual property rights. Any use of the information contained herein (including but not limited to, total or partial reproduction, communication or distribution of any form) by persons other than the designated recipient(s) is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. Ion Beam Applications does not accept liability for any such errors. Thank you for your cooperation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Philippe Andersson

11:56

On 26/05/2020 10:17, Philippe Andersson wrote:

...

On 26/05/2020 10:04, Andrei Borzenkov wrote:

...
On Tue, May 26, 2020 at 10:36 AM Philippe Andersson wrote:

...
...
Sorry Andrei, I should have said: openSUSE 15.1 and SLES 15.

systemd has support for caching passwords since version 227. My understanding was that this caching was done by Plymouth, as called by /usr/lib/dracut/modules.d/90crypt/crypt-lib.sh.

...
Leap 15.1 has systemd 234 so it should work as long as you use standard systemd mechanism for working with encrypted containers. That is what I tested in TW. I will check Leap this evening.

Thanks -- I'll setup a test VM to play with this as well. I played with my test VM (openSUSE Leap 15.0, systemd 234), and you are correct: text-mode prompt also features some password caching mechanism.

What I did: - created a 2nd encrypted LV (with same passphrase as 1st one) - verified that a single password prompt unlocked both LVs using Plymouth - at next reboot, replaced "splash=quiet" with "nosplash" on the kernel boot line (by pressing 'e' in grub menu) Result: - no more splash screen (kernel/systemd messages on the console) - text-based prompt for LUKS passphrase - that single prompt unlocked *both* LVs I'll try to check SLES 15 now. Ph. A. -- *Philippe Andersson* Unix System Administrator IBA Particle Therapy | Tel: +32-10-475.983 Fax: +32-10-487.707 eMail: pan@iba-group.com http://www.iba-worldwide.com Disclaimer | Use of IBA e-communicationhttps://iba-worldwide.com/disclaimer The contents of this e-mail message and any attachments are intended solely for the recipient (s) named above. This communication is intended to be and to remain confidential and may be protected by intellectual property rights. Any use of the information contained herein (including but not limited to, total or partial reproduction, communication or distribution of any form) by persons other than the designated recipient(s) is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. Ion Beam Applications does not accept liability for any such errors. Thank you for your cooperation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov

12:29

On Tue, May 26, 2020 at 2:56 PM Philippe Andersson wrote:

...

- at next reboot, replaced "splash=quiet" with "nosplash" on the kernel

It does not disable plymouth. It only disables plymouth splash screen, but plymouth daemon is still started. You need plymouth.enable=0 to completely suppress plymouth startup. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Philippe Andersson

12:37

Disclaimer | Use of IBA e-communicationhttps://iba-worldwide.com/disclaimer The contents of this e-mail message and any attachments are intended solely for the recipient (s) named above. This communication is intended to be and to remain confidential and may be protected by intellectual property rights. Any use of the information contained herein (including but not limited to, total or partial reproduction, communication or distribution of any form) by persons other than the designated recipient(s) is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. Ion Beam Applications does not accept liability for any such errors. Thank you for your cooperation.

Vojtěch Zeisek

09:02

Dne úterý 26. května 2020 10:04:18 CEST, Andrei Borzenkov napsal(a):

...

On Tue, May 26, 2020 at 10:36 AM Philippe Andersson wrote:

...
Sorry Andrei, I should have said: openSUSE 15.1 and SLES 15.

systemd has support for caching passwords since version 227. Leap 15.1 has systemd 234 so it should work as long as you use standard systemd mechanism for working with encrypted containers. That is what I tested in TW. I will check Leap this evening.

Interesting. I use standard encryption mechanism in TW (single disk, encrypted LVM containing whole root and swap, only /boot/efi is unencrypted) and I enter password before entering GRUB (as expected), but also once more in early boot stage. I'm not sure if this is the same case, I also wonder if I can avoid double entering password, if systemd 234 would fix this...? -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/

Andrei Borzenkov

12:32

On Tue, May 26, 2020 at 12:02 PM Vojtěch Zeisek wrote:

...

Dne úterý 26. května 2020 10:04:18 CEST, Andrei Borzenkov napsal(a):

...
On Tue, May 26, 2020 at 10:36 AM Philippe Andersson wrote:

...
Sorry Andrei, I should have said: openSUSE 15.1 and SLES 15.

systemd has support for caching passwords since version 227. Leap 15.1 has systemd 234 so it should work as long as you use standard systemd mechanism for working with encrypted containers. That is what I tested in TW. I will check Leap this evening.

Interesting. I use standard encryption mechanism in TW (single disk, encrypted LVM containing whole root and swap, only /boot/efi is unencrypted) and I enter password before entering GRUB (as expected), but also once more in early boot stage. I'm not sure if this is the same case,

No, it is not.

...

I also wonder if I can avoid double entering password, if systemd 234 would fix this...?

It has nothing to do with systemd. There is no way to pass password from bootloader to kernel in Linux. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

1443

Age (days ago)

1444

Last active (days ago)

List overview

Download

17 comments

6 participants

participants (6)

Adam Majer
Adam Mizerski
Andrei Borzenkov
Carlos E. R.
Philippe Andersson
Vojtěch Zeisek

[opensuse] LUKS decryption password requested multiple times during boot in text mode

tags

participants (6)