Tell me more ×
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.
up vote 8 down vote favorite
3

I have a fully encrypted server running Debian 6 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?

Update Disabling the firewall makes no difference: nmap shows all ports still closed. I can, however, ping the machine.

Update 2 I believe that the issue is that dropbear is not running as the intramfs is not being correctly built.

I have tried the fixes in this open bug report, including a custom hook to ensure that the correct libraries are copied across to the initrd image, but still encounter the same problem.


  1. The full error, when ssh -vvv is issued:
OpenSSH_5.9p1, OpenSSL 1.0.1a 19 Apr 2012
debug1: Reading configuration data /home/jason/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.200 [192.168.1.200] port 2200.
debug1: connect to address 192.168.1.200 port 2200: Connection refused
ssh: connect to host 192.168.1.200 port 2200: Connection refused
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
show 5 more comments

2 Answers

up vote 3 down vote
+50

Subject line is plainly wrong. Problem isn't in 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
up vote 2 down vote

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

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.