#2606 Issue closed: Remote unlock SED via PBA¶
Labels: support / question, fixed / solved / done
Jip-Hop opened issue at 2021-04-27 19:30:¶
In addition tot the current unlock feature, I'd like to be able to unlock the SED over the network via the PBA in case I don't have a keyboard (and monitor) attached to my home server. This would also allow me to unlock the SED and boot the server if I'm not at home if I use a VPN.
For this reason I'm trying to re-enable networking in the PBA. I've set these to yes:
And commented this line:
https://github.com/rear/rear/blob/6a3d0b4d5e73c69a62ce0bd209b2b38ffb462569/usr/share/rear/build/OPALPBA/Linux-i386/095_exclude_non_essential_files.sh#L20
When I boot from the PBA I drop to an emergency shell but I'm unable to ping anything. If I check ifconfig then there's only the lo network (no eth). What are the additional steps I should take to re-enable networking in the PBA?
If I can re-enable networking I'd try to remotely unlock using SSH. But ultimately I'd make a small HTTPS server with Python which would ask for the password and call sedutil-cli to unlock the disk.
OliverO2 commented at 2021-04-27 20:20:¶
For a (hopefully) complete list of files making PBA support possible, use:
find usr -iname \*opal\* -exec find '{}' -print \;
You might want to look at
usr/share/rear/skel/default/etc/scripts/unlock-opal-disks which
choreographs the final PBA boot stage and deals with final
initialization, password entry and unlocking. It is called via
usr/share/rear/skel/OPALPBA/etc/inittab or
usr/share/rear/skel/default/usr/lib/systemd/system/sysinit-opalpba.service
(depending on whether you are using init or systemd).
In the PBA, networking, sshd and stuff are intentionally left out to
keep it small, simple and secure. Python is generally not available on a
rescue system or PBA. Keep in mind the size limit for a PBA.
Note that all of this is well beyond scope for the current PBA implementation, so you're pretty much on open waters. Currently, remote unlocking requires firmware-level remote control capabilities (e.g. via IPMI oder AMT). Hope this helps anyway. Good luck!
Jip-Hop commented at 2021-04-28 06:46:¶
Thanks for replying so quickly :)
My home server doesn't have IPMI and I'd prefer not to add it just for unlocking the PBA since it would constantly consume power.
I manually made a PBA image containing everything I need (including sedutil-cli, Python and networking) based on Tiny Core Linux. I still had room to spare, so I'm not worried about the PBA size limit.
I understand why networking is currently not available in the PBA image. Networking works in the rear rescue image though. I'm trying to discover why it works in the rescue image, and not in the PBA, so I can reenable it. Do you have another clue?
The rear workflow to generate a PBA image is super convenient! So I was hoping to build on top of it.
OliverO2 commented at 2021-04-28 11:24:¶
Unfortunately, I cannot point specifically to what you might be missing. As far as I remember, stripping down ReaR to meet PBA requirements was a complex multi-step process with a considerable amount of trial and error involved.
Your initial approach is on the right trajectory. However, rather than
changing settings to different values, just comment out the lines you
think might exclude stuff you need. For example, in
001_configure_workflow.sh do not set USE_DHCLIENT='yes', but make
that line # USE_DHCLIENT='no'. The reason is that there are
auto-detection and auto-configuration options in place which adapt to
different installations and operating systems. See
usr/share/rear/conf/default.conf for explanations.
So I'd go further down that route of initially commenting out everything
that looks like a strip-down setting in 001_configure_workflow.sh,
095_exclude_non_essential_files.sh, including COPY_AS_IS_EXCLUDE
lines (you might miss important configuration files otherwise). Also
consider the hints mentioned in my previous comment. Then you could
enable the debug shell via OPAL_PBA_DEBUG_PASSWORD (as explained in
usr/share/rear/conf/default.conf), boot the image via a USB stick and
check what's available.
Note that much depends on your base operating system and its configuration. ReaR images are generally way different from Tiny Core as the former can vary wildly depending on which OS they were created with.
Jip-Hop commented at 2021-05-14 18:17:¶
Thanks again for replying. I went the Tiny Core Linux road after all for my PBA, but did borrow the rear SED unlock code from opal-functions.sh and unlock-opal-disks. I hope you don't mind 🙂
OliverO2 commented at 2021-05-14 19:04:¶
You're welcome! If it works best for you that way, it's perfectly fine. As ReaR code is GPL-licensed, who could object? 😃
jsmeix commented at 2021-05-17 13:31:¶
@Jip-Hop
feel free to 'borrow' ReaR code as you like under GPL license
and ideally you may even bring something back to ReaR at a later time
if you have adaptions and enhancements that could also improve ReaR :-)
[Export of Github issue for rear/rear.]