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

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

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=

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:


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

  • 1
    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, 2012 at 1:58
  • 1
    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, 2012 at 2: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, 2012 at 3:45
  • Can you (temporarily) remove the LUKS encryption and verify that drop bear is actually running?
    – emory
    Apr 22, 2012 at 18:51
  • 1
    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 8, 2012 at 9:17

3 Answers 3


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:


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, 2014 at 0: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, 2014 at 13:07

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 4, 2012 at 23:38

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.

  • @camh, are there any rules regarding that?
    – poige
    May 7, 2012 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 7, 2012 at 11:56
  • @camh, I see...
    – poige
    May 7, 2012 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, 2014 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, 2014 at 20:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .