How to open a port early in boot process to unlock LUKS via SSH

Question

I have a fully encrypted server running Debian 7 and have set up dropbear and busybox to unlock the LUKS container via SSH (as described in this tutorial and in this U&L answer).

Unfortunately, whenever I try and SSH to the server (over the LAN) at reboot, I get a "Connection refused" error. I have tried telnet and nmap to the default port (22) and both say the port is closed.

The server has a ufw rule to accept all traffic from the LAN:

Anywhere         ALLOW       192.168.1.0/24

I have tried changing the port that dropbear listens on in /etc/defaults/dropbear but ssh and telnet are still refused connections¹.

How can I ensure that a port is open at that stage in the boot process so that I can connect to unlock the LUKS container?

Disabling the firewall makes no difference: nmap shows all ports still closed.

Update 2/14

I added break=premount to the kernel line and had a poke around in the initramfs. dropbear has started, but the network is not up at that point. After exiting, the network comes up and boot continues until the prompt to unlock the LUKS device.

At this point, the network is up, and the host has been assigned the correct IP address, but port 22 is still closed.

The IP line in /etc/initramfs-tools/intiramfs.conf I am using is:

export IP=192.168.1.200::192.168.1.1:255.255.255.0::eth0:off

Consistent with the directions in /usr/share/doc/cryptsetup/README.remote.gz I have tried just adding the device option, but that is not sufficient to bring the network up and obtain a dhcp lease.

Update 11/10/14

Karl's answer was what was required: setting up /etc/initramfs-tools/conf.d/cryptroot was the key:

target=md1_crypt,source=UUID=8570d12k-ccha-4985-s09f-e43dhed9fa2a

This guide also proved more up-to-date and relevant (and successful).

WOW! I completely did not know you could remotely unlock a fully locked LUKS. Obviously I can not answer your question w/certainty but I would guess sshd has not started. In my machine, sshd starts later in the process. — emory, Apr 22 '12 at 01:58
Do you have console access to the machine while it's in the busybox environment? Can you verify that dropbear is actually running (via ps) and listening on the port you expect (via netstat)? — larsks, Apr 22 '12 at 02:15
larsks - no, because at the console the prompt is waiting for the passphrase to be entered, and switching to another TTY just means a blank screen (if I understood you correctly). — jasonwryan, Apr 22 '12 at 03:45
Can you (temporarily) remove the LUKS encryption and verify that drop bear is actually running? — emory, Apr 22 '12 at 18:51
emory - I suspect that you are right; but I'm not prepared to remove the encryption to confirm that - I don't see how I can do that without risking the installation. — jasonwryan, Apr 22 '12 at 19:49
Could you start your machine fully and verify in which order are launched dropbear, sshd and LUKS. If your system is using the traditional init system, then it's a matter of looking in /etc/rcN.d where N is the default runlevel (usually 3 or 5). The scripts are run in the alphanumerical order. — Huygens, May 04 '12 at 11:35
Huygens - the order is: S01fancontrol S01rsyslog S01sudo S02acpid S02atd S02cron S02dropbear S02exim4 S02mdadm S02ntp S02rsync S02ssh S03bootlogs S16portmap S17nfs-common S18nfs-kernel-server S19rc.local S19rmnologin S19stop-bootlogd — jasonwryan, May 04 '12 at 22:57
Have you tried using one of the break=X boot parameters to get an early initramfs shell? Whenever I debug filesystem encryption woes, I use break=premount. You can check what the situation is, resolve it, and continue booting. — Alexios, May 08 '12 at 09:17
Alexios - thanks: that's a great tip. I'll reboot when I next have access to the box and run some diagnostics. — jasonwryan, May 09 '12 at 07:28
@jasonwryan, I suggest you setup a testing VM and experiment in a VM. — Zoredache, May 09 '12 at 19:59

score 3 · Accepted Answer · edited Apr 18 '19 at 11:46

I got this same problem a few weeks ago (Debian Wheezy 7.6) and after some days of troubleshooting I found out that there was a config file missing which was preventing to the cryptroot script on init-top to run correctly, hence it was not stopping to ask the password via ssh, killing the dropbear at the end of the sequence (init-bottom).

The config file is called cryptroot and should be under /etc/initramfs-tools/conf.d/ If I am not mistaken that config file should have been created automatically during install (I have read just one tutorial talking about that config file) but somehow it did not (tested in a physical server and in a VM, same OS and versions)

It took me a couple of tries to configure it properly, since I could not find the proper syntax at that time. My cryptroot config file is as follows:

target=crypt-root,source=/dev/vg0/root,lvm=root

Once created the config file just update the initramfs and try again:

update-initramfs -u

You are a LEGEND! Thank you: I had struggled with this for ages and had pretty much given up hope of resolving it. My cryptroot syntax is different to yours, but your answer was enough to point me in the right direction. I'm indebted to you. — jasonwryan, Oct 11 '14 at 00:16
I'm glad you finally got it working. I saw your question while I was investigating my problem and I thought I should post how I resolved it once I got it running. — Carlos, Oct 11 '14 at 13:07

score 3 · Answer 2 · edited Apr 05 '19 at 23:49

The dropbear (ssh server) is supposed to be started very early during boot phase - earlier than the init (rcN.d) sequence and firewall init scripts; even earlier than / is mounted (it is encrypted too, right?). So it comes to initramfs, the pre-/ userland loaded for kernel by boot loader. The image is (re)generated by update-initramfs -u from contents of /etc/initramfs-tools/, including dropbear configuration in /etc/initramfs-tools/etc/dropbear/. To play with dropbear config, play with that one.

Thus, few points to check:

dropbear doesn't start: it haven't been plugged into initramfs sequence well;
default firewall denies all.

Thanks yarek: I think you are right - I have updated my question with a debian bug (and a fix that doesn't work). I have also tried disabling the firewall. — jasonwryan, May 04 '12 at 23:38

score 2 · Answer 3 · edited Feb 13 '14 at 19:49

2

The subject line is wrong. The problem isn't a closed port, it's a port which wasn't bound. SSHd hasn't started yet; that's the reason you can't connect to it.

edited Feb 13 '14 at 19:49

Michael Mrozek

93,103
40
240
233

answered May 04 '12 at 12:28

poige

6,231

@camh, are there any rules regarding that? – poige May 07 '12 at 11:46
I was more focusing on the first sentence, which is editorial. The rest is rather terse to be a good answer, but I guess is still an answer. I'll remove my comment. – camh May 07 '12 at 11:56
@camh, I see... – poige May 07 '12 at 12:32
I'm not using sshd: as the question states, I'm attempting to connect to a dropbear instance that runs on port 22 by default. – jasonwryan Feb 13 '14 at 20:01
@jasonwryan, it doesn't play any role what exactly TCP service you're trying to use, what really matters is it's not started. – poige Feb 13 '14 at 20:04
So, an answer would include information about starting it, would it not? – jasonwryan Feb 13 '14 at 20:08
@jasonwryan, so you want me to fix your problem? :) – poige Feb 14 '14 at 03:56
Well, I thought that was the point of the site :) I'll spend some time this weekend debugging in the initramfs and see what I turn up... – jasonwryan Feb 14 '14 at 04:01

How to open a port early in boot process to unlock LUKS via SSH

Update 2/14

Update 11/10/14

3 Answers3

Linked