Check if it works with Debian 9

[fetzerms]

Currently, I am not sure if this works with Debian 9 - Can anybody test and verify?

[sscheib]

I am right now (literally at the moment) setting up a keyvm and cryptvm both with stretch to test exactly that. I will reply later (or at latest tomorrow) whether it worked out or not.

[fetzerms]

If it works (or not) - feel free to update the table and file a pull request.

[sscheib]

So, in short: No it does not work.

To get more technical: The initramfs-tools behaviour has changed, and the root directory is not anymore static like it used to be, but suffixed with 6 random alphanumeric characters. I think as a workaround one could first get the current root directory like follows: ROOTDIR="$(cd "${DESTDIR}"; echo root-*)" With this you could dynamically configure everything needed.

However, as the behaviour from initramfs-tools behaviour changed, i think it does not copy over files from /etc/initramfs-tools/root - these files have to be referenced directly.

For example in the unlock-keys script (I needed to use the quote tag, as for some reason the code tag wont get evaluated in this case ..)

!/bin/sh

PREREQ=""

prereqs() { echo "$PREREQ" }

case $1 in prereqs) prereqs exit 0 ;; esac

if [ ! -x /usr/bin/ssh ]; then exit 0 fi

. /usr/share/initramfs-tools/hook-functions

ROOTDIR="$(cd "${DESTDIR}"; echo root-*)" cp /root/.ssh/unlock_rsa "${DESTDIR}/${ROOTDIR}/.ssh/" cp /root/.ssh/unlock_rsa.pub "${DESTDIR}/${ROOTDIR}/.ssh/" cp /root/.ssh/known_hosts "${DESTDIR}/${ROOTDIR}/.ssh/"

As I am currently really not in the mood to debug the error I have (I could build the initramfs with the mentioned modifications - of course you need to adapt them to the other scripts as well - but for some reason I cannot retrieve the crypt key. I guess somewhere I have forgotten to change the port (as I am running sshd on a different port) I might take a look at this in a few days/weeks.

Oh by the way (offtopic): Unlocking via SSH works differently in the meanwhile as well. The cryptroot unlock is done using the grub ip command (don't forget to disable net.ifnames=0 biosdevname=0 ..)

[sscheib]

Okay, lets fucking go!

The issue is found within this file: /lib/cryptsetup/scripts/get_key_ssh

For starters ifconfig is deprecated and one needs to use ip to get the macadress. I modified it to look like the following (I have two interfaces and eth1 is the one I use to connect to the cryptvm): mac="$(ip -4 -o link | grep eth1 | sed -E 's/.*link\/ether\s//' | awk '{print $1}')"

But the issue I didn't get it in the first place is, that for some reason the known_hosts file and the public-key were referenced here as well: ssh -i **/root/.ssh/**unlock_rsa -o "UserKnownHostsFile=**/root/.ssh/**known_hosts ConnectTimeout=100" KEYHOST_ADDRESS "$mac"

The problem is simply, that the bold marked directories are - as said in my other comment - not static anymore. So one either has to use the same workaround as above or simply remove the two cli arguments: ssh -p <PORT> <USER>@<KEYHOST_ADDRESS> "$mac"

I chose the latter, as I don't allow root logins anyway and therefor I only have one public-key there.

[sscheib]

I will create a pull request in the upcoming weeks, when i come up with an idea how I can merge these two approches together - shouldn't be that hard.

Awesome project BTW! 👍

[fetzerms]

Thanks for all your debugging! Maybe we should abandon all the MAC-Address stuff. I think using only pubkeys should be far enough. This would purify the code a little as well.

[fetzerms]

@sscheib Any updates on this one? I recently had no time to dig deeper into this, unfortunately.

[sscheib]

I haven't had any time myself, unfortunately. Whenever I'll find some time I try to refactor the code (as you proposed removing the MAC address stuff) and create another pull request. However I can't estimate when I will find enough time to do so - sorry!

[459below]

I apologise for not reading the thread thoroughly. I currently don't have the time.

I just wanted to mention that I have been using these scripts to unlock both a Stretch and a Buster for quite some time, without any issues.

[fetzerms]

@459below are you using fresh installs? With systemd etc?

[459below]

My Stretch install was fresh. Setting up cryptboot-ssh was actually one of the very first things I did. There could've been a few minute things I had to change, but I don't remember having major problems with it on Stretch. The Buster install is fairly old. Should have been Testing when Stretch wasn't released yet. The cryptboot survived for quite some time without breaking down.

And yes everything is running glorious systemd. It does even play nicely with systemd-networkd.

[fetzerms]

I think I need to verify this. According to @sscheib some manual work had to be done. I will try to reproduce this in the next few weeks - tho my time currently is quite limited.

[459below]

That could very well be. My Stretch is producing working initramfs. I will look into them and post any diverging modifications.

[459below]

OK, so far it does not seem that get_key_ssh, ssh-client and unlock-keys would need to be modified in order to work on Stretch. However I may have modified something else in the system. To test it, one should probably set up a fresh install to test this out.

In the meantime I would suggest adding a may into the section of the readme: "scripts are currently not working". Since it most definitely does work essentially.

[fetzerms]

Did you need to modify the initramfs hooks? I think we should keep it as "not working" for now, before we verified the opposite.

[459below]

I'm not certain. I'm running a full test from a clean Stretch image. (I can utilize this for development of the Android Keyserver anyway.)

I'm going to propose a few updates to the documentation in a PR. I'm going to do this in a kind of WIP PR, so as that feedback can be given while updates are made.

[fetzerms]

Seems to work.