phantom-node
Cryptreboot does not ask for a password
Hi @pepawel,
I set up everything accordingly. sudo cryptreboot also reboots the system. However, entering the command does not trigger a password prompt and as such the reboot behavior is the same as for sudo reboot and I have to get in front of my system to enter the password.
I am on Ubuntu 22.04.1.
Thanks, Florian
Hi Florian,
Thank you for reporting the issue!
The behavior you are experiencing looks odd to be honest. Cryptreboot should ask you for the password, verify it, report an error, and exit in case it happens to be invalid. If it doesn't ask you for a password, then the verification should fail.
It would help me, if you run this command and provide me with the output:
cat /sys/kernel/kexec_loaded
Then, please run cryptreboot with additional flags to enable debug output and dry-run mode (to prevent the actual reboot):
sudo cryptreboot -dp
The output may contain your disk encryption key, so please remove it before pasting it here. The key is contained after Running cpio -oH newc --reproducible and before This file has been patched by cryptreboot.
Other things should be safe to post publicly. However, if you want, you can remove things such as salt, UUID etc.
Afterward please run the following command (once again) and paste the output:
cat /sys/kernel/kexec_loaded
I hope this additional info will point me into the right direction.
@Ltty I suspect the issue may be related to crypttab file parsing. Could you paste your /etc/crypttab?
Output of cat /sys/kernel/kexec_loaded:
0
Debug output: `sudo cryptreboot -dp [sudo] password for florian: Extracting initramfs... To speed things up, future versions will employ cache. Running (echo lz4 "-t"; strace -f --trace=execve -z -qq --signal=!all unmkinitramfs /boot/initrd.img /tmp/d20240916-115685-r9ozk1) 2>&1 | grep --line-buffered lz4 lz4 "-t" Finished in 58.297 seconds with exit status 0 (successful) Running mount -t ramfs -o mode=700 none /tmp/d20240916-115685-flxyau Finished in 0.014 seconds with exit status 0 (successful) Running cpio -oH newc --reproducible [KEY] This file has been patched by cryptreboot
07070100000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000B00000000TRAILER!!! 2 blocks Finished in 0.005 seconds with exit status 0 (successful) Running cat /boot/initrd.img /tmp/d20240916-115685-flxyau/patch Finished in 0.114 seconds with exit status 0 (successful) Running kexec -al /boot/vmlinuz --initrd /tmp/d20240916-115685-flxyau/result --reuse-cmdline Finished in 0.893 seconds with exit status 0 (successful) Running umount /tmp/d20240916-115685-flxyau Finished in 0.029 seconds with exit status 0 (successful)`
Output of cat /sys/kernel/kexec_loaded:
1
Output of /etc/crypttab:
cryptoswap /dev/sda2 /dev/urandom swap,initramfs
I installed Ubuntu 22.04.1 and was able to replicate the issue. It occurs when choosing ZFS+encryption when installing OS. Am I right you are using this filesystem?
Yes exactly, using ZFS.
Best, Florian
Paweł Pokrywka @.***> schrieb am Fr., 20. Sep. 2024, 12:51:
I installed Ubuntu 22.04.1 and was able to replicate the issue. It occurs when choosing ZFS+encryption when installing OS. Am I right you are using this filesystem?
— Reply to this email directly, view it on GitHub https://github.com/phantom-node/cryptreboot/issues/2#issuecomment-2363436391, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYONIMWC6TK53YJCRKZAODZXP44RAVCNFSM6AAAAABMIKCMSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRTGQZTMMZZGE . You are receiving this because you were mentioned.Message ID: @.***>
Currently, cryptreboot supports LUKS-encrypted volumes described in /etc/crypttab. Encrypted ZFS volumes are not listed in /etc/crypttab, therefore they are invisible to cryptreboot.
Unfortunately, cryptreboot won't work on your machine unless you migrate to LUKS-encrypted volumes. I'm sorry Florian :worried:
I will update README accordingly.
I believe it is possible to extend cryptreboot to support encrypted ZFS. I'm leaving this issue open as a feature request.
Thanks @pepawel, I solved the issue in the meantime by using a different approach. I installed dropbear so I can ssh into initram during boot and decrypt the zfs pool from there.
Do you have instructions to revert the install process and uninstall cryptreboot?
I'm glad you found a solution @Ltty, congrats!
To uninstall cryptreboot, uninstall the gem:
sudo gem uninstall crypt_reboot
You can also remove dependencies if you are sure you don't use them:
gem uninstall tty-command tty-option pastel tty-color memory_locker
By the way, I have been working on adding ZFS support to cryptreboot for the last couple of days. I managed to perform a successful reboot with it on my encrypted Ubuntu 22.04 ZFS-enabled installation. I will post more details here soon.
The support for ZFS is there. If you want to give it a shot, you can install it with:
sudo gem install crypt_reboot --pre
To verify you use correct version run:
cryptreboot -v
It should be 0.3.0.beta.1.
Nice, will try that.
The solution with dropbear works nicely, but only if you are in the same network.
Paweł Pokrywka @.***> schrieb am Do., 26. Sep. 2024, 18:14:
The support for ZFS is there. If you want to give it a shot, you can install it with:
sudo gem install crypt_reboot --pre
To verify you use correct version run:
cryptoreboot -v
It should be 0.3.0.beta.1.
— Reply to this email directly, view it on GitHub https://github.com/phantom-node/cryptreboot/issues/2#issuecomment-2377399710, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYONIK53O4WVJY5YSHEGRLZYQXH5AVCNFSM6AAAAABMIKCMSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZXGM4TSNZRGA . You are receiving this because you were mentioned.Message ID: @.***>
Works perfectly. It's more convenient compared too dropbear too. For example, I am running my VPN server on this machine. As soon as I reboot, I can only connect to dropbear if I am in the same network as I do not have a vpn connection otherwise.
Thx
That's good to hear! I'm glad I could help.
I've polished ZFS support and released a new, stable 0.3.0 version. To update, run:
sudo gem install crypt_reboot
Thank you for reporting the issue, Florian. Thanks to this, I could understand ZFS and ZFS encryption in Ubuntu better, improving cryptreboot at the same time. Please let me know if you find any other issues.
I would be grateful for a star on the cryptreboot project page on GitHub :)