Open mvforell opened 1 month ago
What Linux distribution are you running on your RPi?
I'm using Arch Linux ARM.
I'm not familiar with Arch, thus I don't know whether it packages sshd/dracut significantly different than other distributions.
However, another thing to check is the service type of the early sshd.
By default, dracut-sshd expects sshd to support systemd style notification support, cf. the comments in the service file and README:
However, 2 s seems to be a bit short for hitting the default timeout, when an expected notification doesn't arrive.
Otherwise it looks like the early boot environment kills your sshd because it proceeds with switching root.
Usually, the switch-root target should be blocked by an encrypted volume that isn't unlocked yet, if it contains a filesystem that is required by later boot.
Thus, perhaps something changed in that corner of your setup.
To investigate it further you can check whether any root=,,, rd.luks.uuid=...
kernel parameters and/or crypttab files that are included in your initramfs still make sense.
Thanks for your reply! I'm quite busy at the moment, but I will look into this some more based on your suggestions once I find the time.
I've been using dracut-sshd for quite some time now on my Raspberry Pi 4 to remotely unlock a LUKS volume, and it's been working just fine since I set it up. So first of all, thank you for this project!
However, today I seem to have changed something that caused my setup to not work any more. The only thing that I remember changing was that I added a new key to
/etc/dracut-sshd/authorized_keys
; then I regenerated the initramfs and rebooted. Since then I'm unable to SSH into the machine, and I've been unable to find out why exactly. (I'd be surprised if that was what caused this issue, most likely I forgot about something else I did between the last reboot that worked and this next, failed reboot.)I hooked the RPi up to a monitor and connected a keyboard so I could access the emergency shell. There, everything seems to be working fine (network etc.), but for some reason the sshd service is automatically stopped ~2 seconds after it successfully started.
This is the output of
journalctl -b | grep -C 5 sshd
from the emergency shell:journalctl -b | grep -C 5 sshd
Some excerpts that seem relevant to me:
I'm not super familiar with systemd, so I don't really have a clue what could be causing the service to be stopped.
I'd be very grateful for tips on how to further debug this, or maybe you already have an idea how to fix the issue.