mirror of
https://github.com/ovh/the-bastion.git
synced 2026-05-09 16:35:33 +02:00
[GH-ISSUE #563] Expected behavior for /home encryption ? #145
Labels
No labels
answered
bug
documentation
enhancement
enhancement
feature
feature
kept-open-for-info
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/the-bastion#145
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @DavidutzDev on GitHub (Jul 10, 2025).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/563
Hello,
I'm exploring The Bastion and I am not sure if I found unexpected behavior for Bastion or it's the expected one. I didn't found anything talking about it in the documentation or I just omit one step during the configuration.
For short, after rebooting the Bastion server (I won't be able to say how many), I wasn't able to connect anymore to my users using the correct certificates. That happens only on servers where I enable the encryption of the
/home(using/opt/bastion/bin/admin/setup-encryption.sh). I don't get the issue when I don't enable it but that's still annoying. Maybe I missed something during the installation or an extra step.I also noticed a
<<LOCKED>>root@when connection to the root ssh (root being the only available user, since I guess the mount point isn't the same /root). I managed to unlock the solution temporary by usingcryptsetup status homeandcryptsetup luksOpen /dev/sda6 homemount /dev/mapper/home /home.I was asking myself if it's the correct behavior or not but I might found the correct one by myself. Not sure about the last statement so that's why I post this here. It might be helpful for someone and I hope getting an answer on this.
Thanks for the project
@speed47 commented on GitHub (Jul 12, 2025):
Hello,
The fact that after rebooting, the encrypted partition is locked, is the expected behavior. An admin intervention (as root) is needed to provide the LUKS password and unlock the partition.
There is a helper script to do that, if it's not in the encryption documentation, it's an omission and I'll add it: the script is
unlock-home.shunder the bin/admin` hierarchy.Note that if you'd like the partition to be automatically unlocked upon rebooting, this is possible: if you have a TPM in your hardware, you may enable secure boot and store the LUKS password in the TPM. This is completely out of scope of The Bastion, as this is a Linux/distro thing, which is why it's not documented here, but I may add a note to state this in the documentation for clarity, if it helps!
@DavidutzDev commented on GitHub (Jul 12, 2025):
Thank you for your reply,
I bet there's no information on the documentation but thanks for clarifying it !