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

Open encrypted volume from already booted system. #43

Open
peto59 opened this issue Aug 8, 2024 · 2 comments
Open

Open encrypted volume from already booted system. #43

peto59 opened this issue Aug 8, 2024 · 2 comments

Comments

@peto59
Copy link

peto59 commented Aug 8, 2024

Hello.

Is there a way to open encrypted volume similar to cryptsetup luksOpen /dev/sdX? I've inserted encrypted disk into another machine, therefore I do have access to the ykfde-challenges.img file in /boot as the're on separate partition but I have no idea how to actually open and mount the encrypted partition.

Any help is appreciated.

@eworm-de
Copy link
Owner

eworm-de commented Aug 8, 2024

Hmm, this is to recover a system or what is your intention? Just citing from documenting:

Be warned: Do not remove or overwrite your interactive (regular) key! Keep that for backup and rescue - LUKS encrypted volumes have a total of 8 slots (from 0 to 7).

So you have your regular key around and can use that to open the volume, no?

If not... Well, there is no out-of-the-box way to do what you want. It is possible for sure to do that manually, but kind of tricky. I would have to look up things myself...

@peto59
Copy link
Author

peto59 commented Aug 8, 2024

Thanks for quick reply.

Yes, this is for recovery. Either from another machine or live enviroment, doesn't really matter which. The installation is just a test, so no data is at risk currently, but I'd like to move this solution to production as I really like your project.

I am aware that you've warned users to not remove interactive key, but I decided to do so anyways in spirit of testing and because as I've already said, there's no downside to formating the disk at this time.

And the reason that I ignored this warning is that the system is as secure as it's weakest link. Leaving interactive key in LUKS header defeats the whole purpose of needing to use yubikey in case of stole disk or device, at lest in my opinion, correct me if I'm wrong.

From my point of view (which is propably very wrong) all the functionality for asking user for second factor, decrypting device and mounting it in /dev/mapper/ is already present so it shouldn't be much work to implement something along the lines of ykfde open --ask-2nd-factor --challenge=/mnt/boot/ykfde-challenges.img --mount=root_crypt which would mount the device specified in ykfde.conf to /dev/mapper/root_crypt. Even the --mount is unnecesary as rewriting ykfde.conf and /etc/crypttab.initramfs from scratch for single device takes just few seconds. Again, correct me if I'm wrong.

Looking forward to your reply.

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

No branches or pull requests

2 participants