pwmake error trying to bind to tang server

[mrvanhorn]

Both server and client are running CentOS 7.9.

I'm tying to bind to a tang server, but am getting an error from pwmake:

# clevis luks bind -d /dev/sdb1 tang '{"url":"http://serverip:port"}'
Usage: pwmake <entropy-bits>
#

I have ensured that the server is responding (using "curl http://serverip:port/adv"), so the problem shouldn't be that the client isn't getting a response from the server. It seems like the sed of 'cryptsetup luksDump' in /usr/bin/clevis-luks-bind isn't returning a number (which should be 256, in my case). Am I missing something?

[afunix]

Same here on CentOS 7. @mrvanhorn were you able to fix it?

[sarroutbi]

Hello. Could you please:

1. Paste output of "lsblk --fs" command?
2. Paste output of "cryptsetup luksDump /dev/sdb1" command?
3. Paste output of 'cryptsetup isLuks --type luks1 /dev/sdb1 && echo "LUKS1"' command?
4. Paste output of 'cryptsetup isLuks --type luks2 /dev/sdb1 && echo "LUKS2"' command?

[afunix]

For whoever faced this. This is likely due to LUKS2, which is not supported by clevis on CentOS7. You can still convert LUKS2 back to compatible LUKS1.

Eg: cryptsetup luksConvertKey --pbkdf=pbkdf2 /dev/sda2 cryptsetup convert /dev/sda2 --type luks1

[mrvanhorn]

Same here on CentOS 7. @mrvanhorn were you able to fix it?

No, I never got it working. It worked in my test vm just fine, but doing exactly the same process on a real machine, and it just didn't work. This is the same behaviour one of my colleagues has seen; it works fine on one system, but then just doesn't on another. Or, it works until there's an update, and then it quits working.

I have been told it works better in EL8, but I haven't had time to try it with an EL8 client yet.

[mrvanhorn]

For whoever faced this. This is likely due to LUKS2, which is not supported by clevis on CentOS7. You can still convert LUKS2 back to compatible LUKS1.

Eg: cryptsetup luksConvertKey --pbkdf=pbkdf2 /dev/sda2 cryptsetup convert /dev/sda2 --type luks1

This is not the case for me; both of my tests (the VM where it did work and the physical machine where it didn't) are using LUKS1.

[sergio-correia]

For whoever faced this. This is likely due to LUKS2, which is not supported by clevis on CentOS7. You can still convert LUKS2 back to compatible LUKS1. Eg: cryptsetup luksConvertKey --pbkdf=pbkdf2 /dev/sda2 cryptsetup convert /dev/sda2 --type luks1

This is not the case for me; both of my tests (the VM where it did work and the physical machine where it didn't) are using LUKS1.

Please provide the output of crtypsetup luksDump <device> for the case it is not working. Also, what clevis version are you using?

[mrvanhorn]

Hello. Could you please:

1. Paste output of "lsblk --fs" command?

2. Paste output of "cryptsetup luksDump /dev/sdb1" command?

3. Paste output of 'cryptsetup isLuks --type luks1 /dev/sdb1 && echo "LUKS1"' command?

4. Paste output of 'cryptsetup isLuks --type luks2 /dev/sdb1 && echo "LUKS2"' command?

Here is the output of all of those commands:

Script started on Tue 17 May 2022 02:50:32 PM EDT [root@testing ~]# lsblk --fs NAME FSTYPE LABEL UUID MOUNTPOINT sda
├─sda1 vfat 3A96-73BA /boot/efi ├─sda2 xfs cb006927-a826-4a6c-83c9-afe9f4f493c6 /boot └─sda3 crypto_LUKS 63c26c83-44e8-418b-8150-84b79b4686f7
└─luks-63c26c83-44e8-418b-8150-84b79b4686f7 LVM2_member NSfWWU-RYUM-I863-vnWT-oGUh-B7AQ-eH2NNz ├─centos-root xfs a8962581-d324-40cb-90a8-084b56615f8a / ├─centos-swap swap 7ebf6cb4-134f-42ba-8477-4bcd8495912e [SWAP] └─centos-home xfs 1dbbcd56-3c9a-462b-b5f5-767ef79bff1b /home sr0
[root@testing ~]# cryptsetup luksDump /dev/sda3 LUKS header information for /dev/sda3

Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha256 Payload offset: 4096 MK bits: 512 MK digest: 80 c3 0a a7 96 0a a7 9a 5d f5 23 8f ff 15 22 12 93 04 aa 29 MK salt: 5f 87 fc 63 ca e6 77 34 fa 44 2f b6 d2 72 7d 4b 98 3a 7c 09 86 33 ea 5c 90 64 7d 50 51 d3 7c 4f MK iterations: 21750 UUID: 63c26c83-44e8-418b-8150-84b79b4686f7

Key Slot 0: ENABLED Iterations: 172505 Salt: e7 4c 71 74 dd 0a 68 dd 70 45 41 4c b9 a0 1e 33 88 5b 31 c2 e7 fb ac 0e 81 1e 12 90 99 09 c7 38 Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: ENABLED Iterations: 411528 Salt: 91 99 72 ed 32 09 b2 76 07 74 72 66 00 0a 95 c7 5f 21 b9 e9 5f 68 aa 39 9c 7d cb 06 cc e9 a0 68 Key material offset: 1520 AF stripes: 4000 Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED [root@testing ~]# cryptsetup isLuks --type luks1 /dev/sda3 && echo "LUKS1" LUKS1 [root@testing ~]# cryptsetup isLuks --type luks2 /dev/sda3 && echo "LUKS2" [root@testing ~]# exit

Script done on Tue 17 May 2022 02:51:25 PM EDT

[mrvanhorn]

For whoever faced this. This is likely due to LUKS2, which is not supported by clevis on CentOS7. You can still convert LUKS2 back to compatible LUKS1. Eg: cryptsetup luksConvertKey --pbkdf=pbkdf2 /dev/sda2 cryptsetup convert /dev/sda2 --type luks1

This is not the case for me; both of my tests (the VM where it did work and the physical machine where it didn't) are using LUKS1.

Please provide the output of crtypsetup luksDump <device> for the case it is not working. Also, what clevis version are you using?

The luksDump output is

[root@testing ~]# cryptsetup luksDump /dev/sda3 LUKS header information for /dev/sda3

Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha256 Payload offset: 4096 MK bits: 512 MK digest: 80 c3 0a a7 96 0a a7 9a 5d f5 23 8f ff 15 22 12 93 04 aa 29 MK salt: 5f 87 fc 63 ca e6 77 34 fa 44 2f b6 d2 72 7d 4b 98 3a 7c 09 86 33 ea 5c 90 64 7d 50 51 d3 7c 4f MK iterations: 21750 UUID: 63c26c83-44e8-418b-8150-84b79b4686f7

Key Slot 0: ENABLED Iterations: 172505 Salt: e7 4c 71 74 dd 0a 68 dd 70 45 41 4c b9 a0 1e 33 88 5b 31 c2 e7 fb ac 0e 81 1e 12 90 99 09 c7 38 Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: ENABLED Iterations: 411528 Salt: 91 99 72 ed 32 09 b2 76 07 74 72 66 00 0a 95 c7 5f 21 b9 e9 5f 68 aa 39 9c 7d cb 06 cc e9 a0 68 Key material offset: 1520 AF stripes: 4000 Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED [root@testing ~]#

Yum shows the clevis version to be "7-8": clevis.x86_64 7-8.el7 @base
clevis-dracut.x86_64 7-8.el7 @base
clevis-luks.x86_64 7-8.el7 @base
clevis-systemd.x86_64 7-8.el7 @base

[sarroutbi]

Sorry, but I can not figure out what the error could be.

The code parses next line: MK bits: 512

So it should generate password with command:

$ pwmake 512

Can you execute it manually to check if that dumps an error?

[mrvanhorn]

I am able to execute that command on several CentOS 7 machines, with no error. I don't have the machine I was testing on anymore, so I can't try it specifically on that.

I eventually gave up trying to fix this.

[sarroutbi]

Hello @mrvanhorn. IMHO, we should close this. It seems the issue is related to pwmake limit, which was fixed in https://github.com/latchset/clevis/pull/338. If the issue still appears with latest version of Clevis, then we should revisit.

[mrvanhorn]

@sarroutbi Do you know what the fix from #338 was implemented (which release)? I don't see #338 referenced anywhere on https://github.com/latchset/clevis/releases?page=1.

I still haven't gotten to try getting this working again, but if there's a release number, I could try to find a pre-built package from a repo, which would be easier than downloading and compiling myself.

[sarroutbi]

That fix will be generated in next release, it is still pending. I doubt when next release will be launched. Depending on the platform you are using, it could be included (it has been recently ported to Fedora 37 and Fedora 36, for example). It is pending to port to CentOS Stream

[sarroutbi]

@mrvanhorn : Latest release, v19 contains the fix in #338