Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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 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=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).

share|improve this question
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 '12 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 '12 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 '12 at 3:45
    
Can you (temporarily) remove the LUKS encryption and verify that drop bear is actually running? –  emory Apr 22 '12 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 '12 at 9:17

3 Answers 3

up vote 3 down vote accepted
+200

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

Probably you already fixed your issue, but I hope it helps anyone in the same situation.

share|improve this answer
    
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 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. –  Karl Oct 11 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.

Hope this helps.

share|improve this answer
    
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 '12 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.

share|improve this answer
    
@camh, are there any rules regarding that? –  poige May 7 '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 7 '12 at 11:56
    
@camh, I see... –  poige May 7 '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 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 at 20:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.