thereal1604 / disk-encryption-hetzner Goto Github PK

~ # cryptroot-unlock
Please unlock disk cryptroot:
cryptsetup: cryptroot set up successfully
~ # Connection to $IPADDRESS closed by remote host.
Connection to $IPADDRESS closed.

And then ssh -i .ssh/dropbear root@$IPADDRESS
ssh: connect to host $IPADDRESS port 22: Connection refused

until I reboot the server through the robot.

see title.

I followed the Debian Guide (SWRAID-1 LVM LUKS) and encountered some issue.

Problem 1:

After restoring the vg config I got this message about different sector sizes:

Device /dev/mapper/cryptroot has size of 7812687488 sectors which is smaller than corresponding PV size of 7812720256 sectors. Was device resized?

I was able to solve this by simply deleting the volume group again and re-creating everything from scratch instead of restoring the backup:

vgremove vg0
lvcreate -n home -L100G vg0
lvcreate -n root -L300G vg0
lvcreate -n swap -L32G vg0

Problem 2:

update-grub hangs and shows no output at all. I debugged this by using strace -f update-grub
This did show a problem:

[pid 15012] openat(AT_FDCWD, "/run/udev/data/b1:0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Solution was to also mount /run before chroot'ing:

mount --bind /run /mnt/run

Problem 3:

update-grub now run executes successfully, but the resulting config has an empty root= parameter. Thus after SSH'ing into dropbear and unlocking the cryptroot nothing happened, because grub wasn't able to continue boot. The offending menu entry in grub.cfg looks like

'gnulinux-5.0.21-2-pve-advanced-826c461f-7527-4f81-8899-2752ff825c7c' {
                load_video
                insmod gzio
                if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
                insmod part_gpt
                insmod part_gpt
                insmod diskfilter
                insmod mdraid1x
                insmod ext2
                set root='mduuid/2d47ce5ebb51653216be521ba6329c11'
                if [ x$feature_platform_search_hint = xy ]; then
                  search --no-floppy --fs-uuid --set=root --hint='mduuid/2d47ce5ebb51653216be521ba6329c11'  2c07da8f-e0d8-4dca-b772-df4e7c2fc250
                else
                  search --no-floppy --fs-uuid --set=root 2c07da8f-e0d8-4dca-b772-df4e7c2fc250
                fi
                echo    'Loading Linux 5.0.21-2-pve ...'
                linux   /vmlinuz-5.0.21-2-pve root= ro  nomodeset consoleblank=0
                echo    'Loading initial ramdisk ...'
                initrd  /initrd.img-5.0.21-2-pve
        }

Notice that the root parameter on this line is empty: linux /vmlinuz-5.0.21-2-pve root= ro nomodeset consoleblank=0

This is where I'm stuck now. I was able to to temporary fix it by simpy manually editing /boot/grub/grub.cfg and adding /dev/vg0/root as root argument. But this will obviously get overwritten on the next grub-update. I really dislike grub and I don't know how to make it autodetect. I've spent the last few hours searching for a solution, but grub is such a complex behemoth....

Any ideas/help would be greatly appreciated.

It's great to see that this repo is getting some love, we've gone from one guide to 4 in a few months. However, I can see that without some planning we might just end up with an unmaintainable mess. I'd hate to see everyone's hard work in documenting this process become dated and useless, or worse... confusing!

So the question is, is there a way to structure this repo, or the guides, to make things more maintainable?

I note that other contributors have done some work organising the repo, which is a great start.

The problem we have at the moment is that each guide repeats loads of the content of other guides. (you know... don't repeat yourself). That said it's not as easy as making a single merged guide with annotations for different platforms / configurations, because such a thing would make it more difficult to maintain and less readable.

Maybe a good compromise would be to have a comprehensive "overview" in the front readme, which doesn't include any commands, but explains conceptually what needs to be done at each step. Then the existing guides can have the conceptual wordy stuff removed, and instead just refer to the relevant step from the overview.

Secondly, I think each guide should have certain requirements. For example:

• frontmatter - mention that there's other guides, mention the overview
• headings relating to the steps from the overview
• contrib request - a strong plea to post an issue if a correction is required, and all the info needed when posting such an issue.

Specifically at this step : ssh -i .ssh/dropbear root@ I get a "Warning: Identity file .ssh/dropbear not accessible: No such file or directory." and Permission denied (publickey).

I thought I missed a step and redid the whole process just to end up with the same error.

We noticed there's an easier way to install Hetzner dedicated servers with encrypted HDDs/SSDs, using Hetzner's own installimage system. Basically it is described in https://community.hetzner.com/tutorials/install-ubuntu-2004-with-full-disk-encryption with Ubuntu instead of Debian :)

These instructions use only a single disk, if your server has multiple ones, you can use something like

DRIVE1 /dev/sda
DRIVE2 /dev/sdb
SWRAID 1
SWRAIDLEVEL 1

in /tmp/setup.conf.

The image for debian is

IMAGE /root/images/Debian-1101-bullseye-amd64-base.tar.gz

(also change that in /tmp/setup.conf).

The /tmp/post-install.sh script shown in that blog post works fine for Debian as well.

The only caveat is that the SSH keys you put into /tmp/authorized_keys will afterwards be both used for unlocking and for regular login on the server. I put the unlocking SSH key in there and used it to first login into the real system, and then changed the SSH key for that one to another.

Hi, I am setting up a new server and I am trying to combine the things written down here, here and here.

Especially the last post is super simple. Is there a specific reason why the debian howtos are not making use of the dropbear-initramfs but instead installing busybox dropbear etc separetly?

If all goes well I may contribute a new guide here :)

Depending on the image the hoster offers, lvm2 might not be installed by default. This caused me many hours of pain when I tried to adapt this guide for a different hoster. Unfortunately during debugging Debian / initramfs was not very helpful. Even though I explicitly added lvm2 to initramfs' modules I got no error message about this missing module while building the initramfs. Instead it just silently skipped on including the modules necessary for cryptsetup in initramfs causing cryptroot-unlock to fail with the cryptic error timeout waiting for askpass. You just can't imagine my frustration when it turned out that I spent hours debugging an error, which would have been fixed by a simple apt install lvm2.

TL;DR
don't assume that the hosters os images include lvm2 by default and explicitly add it in all guides: apt install lvm2

I don't know if this project is still active. I just did the installation on Debian 10 and it worked great.

Just an idea, maybe you could add a line to /etc/dropbear-initramfs/config that automatically launches cryptroot-unlock, so the only thing you need to enter in the dropbear ssh is your key:

#/etc/dropbear-initramfs/config
DROPBEAR_OPTIONS="-c /bin/cryptroot-unlock"

Hello,
I have Hetzner SB39 with 2x4TB HDD in MD1 raid. I followed your Ubuntu guide for setup full disk encryption. I have only swap and root logical volumes. I also tried exact partitioning like you with the same error.

I have issue with activating root logical volume after restoring the vgconfig.

root@rescue ~ # vgchange -a y vg0
  WARNING: Device /dev/mapper/cryptroot has size of 7809572480 sectors which is smaller than corresponding PV size of 7809576576 sectors. Was device resized?
  One or more devices used as PVs in VG vg0 have changed sizes.
  device-mapper: reload ioctl on (253:2) failed: Invalid argument
  1 logical volume(s) in volume group "vg0" now active

Verbose mode:

root@rescue ~ # vgchange -v -a y vg0
  WARNING: Device /dev/mapper/cryptroot has size of 7809572480 sectors which is smaller than corresponding PV size of 7809576576 sectors. Was device resized?
  One or more devices used as PVs in VG vg0 have changed sizes.**
    1 logical volume(s) in volume group "vg0" already active
    1 existing logical volume(s) in volume group "vg0" monitored
    Activating logical volume vg0/swap.
    activation/volume_list configuration setting not defined: Checking only host tags for vg0/swap.
    Activating logical volume vg0/root.
    activation/volume_list configuration setting not defined: Checking only host tags for vg0/root.
    Creating vg0-root
    Loading vg0-root table (253:2)
  device-mapper: reload ioctl on (253:2) failed: Invalid argument
    Removing vg0-root (253:2)**
    Activated 1 logical volumes in volume group vg0
  1 logical volume(s) in volume group "vg0" now active

MD replication is done:

root@rescue ~ # cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda2[0] sdb2[1]
      3904788288 blocks super 1.2 [2/2] [UU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

md0 : active raid1 sda1[0] sdb1[1]
      2095104 blocks super 1.2 [2/2] [UU]

unused devices: <none>

root@rescue ~ # pvdisplay
  WARNING: Device /dev/mapper/cryptroot has size of 7809572480 sectors which is smaller than corresponding PV size of 7809576576 sectors. Was device resized?
  One or more devices used as PVs in VG vg0 have changed sizes.
  --- Physical volume ---
  PV Name               /dev/mapper/cryptroot
  VG Name               vg0
  PV Size               3.64 TiB / not usable 1.81 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              953317
  Free PE               0
  Allocated PE          953317
  PV UUID               jcVbkC-Eism-n41u-YsHl-vjqE-amU7-NlmpJB

root@rescue ~ # vgdisplay
  WARNING: Device /dev/mapper/cryptroot has size of 7809572480 sectors which is smaller than corresponding PV size of 7809576576 sectors. Was device resized?
  One or more devices used as PVs in VG vg0 have changed sizes.
  --- Volume group ---
  VG Name               vg0
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               3.64 TiB
  PE Size               4.00 MiB
  Total PE              953317
  Alloc PE / Size       953317 / 3.64 TiB
  Free  PE / Size       0 / 0
  VG UUID               LUusEF-GkHk-w0bL-ru8s-atL6-jcba-9cFJfe

root@rescue ~ # pvresize /dev/mapper/cryptroot
  WARNING: Device /dev/mapper/cryptroot has size of 7809572480 sectors which is smaller than corresponding PV size of 7809576576 sectors. Was device resized?
  One or more devices used as PVs in VG vg0 have changed sizes.
  /dev/mapper/cryptroot: cannot resize to 953316 extents as 953317 are allocated.
  0 physical volume(s) resized / 1 physical volume(s) not resized

root@rescue ~ # lvdisplay
  WARNING: Device /dev/mapper/cryptroot has size of 7809572480 sectors which is smaller than corresponding PV size of 7809576576 sectors. Was device resized?
  One or more devices used as PVs in VG vg0 have changed sizes.
  --- Logical volume ---
  LV Path                /dev/vg0/swap
  LV Name                swap
  VG Name                vg0
  LV UUID                eGvsQS-evml-Pe8r-3Tl5-VDff-MLfn-PSFj4U
  LV Write Access        read/write
  LV Creation host, time rescue, 2018-12-05 11:01:24 +0100
  LV Status              available
  # open                 0
  LV Size                10.00 GiB
  Current LE             2560
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1

  --- Logical volume ---
  LV Path                /dev/vg0/root
  LV Name                root
  VG Name                vg0
  LV UUID                6RXPlI-FWZr-LoKg-ZOwR-I3ha-zljT-Bnc2DK
  LV Write Access        read/write
  LV Creation host, time rescue, 2018-12-05 11:01:24 +0100
  LV Status              NOT available
  LV Size                3.63 TiB
  Current LE             950757
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

I simulated it three times with the same issue.

Thanks for check.

Inquiry cancelled.

I followed the instructions verbatim from the Ubuntu guide and am running into an issue where after running the cryptroot setup script on dropbear, I am unable to SSH into the server. I am not sure if this is has to do with some hooks in initramfs which prevent further SSH attempts into the box, or if it's a problem with the with the LVM setup itself. There is some ambiguity around the instructions describing the LVM process creation.

We have now to edit your vg0 backup:

blkid /dev/mapper/cryptroot Results in: /dev/mapper/cryptroot: UUID="HEZqC9-zqfG-HTFC-PK1b-Qd2I-YxVa-QJt7xQ"
cp vg0.freespace /etc/lvm/backup/vg0
Now edit the id (UUID from above) and device (/dev/mapper/cryptroot) property in the file according to our installation

I wasn't sure exactly where the UUID and device were supposed to go, I put them into the physical volume section of the backup file, but got some warnings later on about sectors not matching. I'm wondering if that's the cause of the issue.