[GH-ISSUE #563] Expected behavior for /home encryption ? #145

Closed
opened 2026-05-07 00:19:24 +02:00 by BreizhHardware · 2 comments

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 using cryptsetup status home and cryptsetup luksOpen /dev/sda6 home mount /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

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 using `cryptsetup status home` and `cryptsetup luksOpen /dev/sda6 home` `mount /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
Author
Owner

@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.sh under 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!

<!-- gh-comment-id:3064939609 --> @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.sh` under 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!
Author
Owner

@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 !

<!-- gh-comment-id:3065967272 --> @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 !
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/the-bastion#145
No description provided.