I'm trying to unlock a headless server running an encrypted version of Ubuntu 14.04. It is a clean 14.04.2 install with all updates as of writing.

I went thtrough the standard shenanigans with dropbear and busybox, i.e.:

sudo apt-get install dropbear busybox           # on server

sudo sed -i 's/NO_START=1/NO_START=0/g' /etc/default/dropber
sudo sed -i 's/BUSYBOX=y/BUSYBOX=y\nDROPBEAR=y\n/g' \
sudo sed -i 's/DEVICE=.+/DEVICE=etho0/g' \
sudo sed -i 's/IP=.+/IP=IP=' \
sudo update-initramfs

# WRONG: sudo cp /etc/dropbear/dropbear_*_host_key /tmp
sudo cp /etc/initramfs-tools/root/.ssh/id_rsa /tmp             # BETTER!
sudo chown $USER:$USER /tmp/id_rsa

scp server:/tmp/id_rsa ~/.ssh/id_rsa_dropbear_server           # on client

sudo reboot                                                    # on server

ssh -vv -i ~/.ssh/id_rsa_dropbear_server \
        -o 'UserKnownHostsFile=~/.ssh/known_hosts.initramfs' \ 
         root@                                     # on client

So I copied the auto-generated ssh-key and did a minimal configuration of dropbear. To my surprise two three things are malfunctioning:

  1. The system ignores the IP settings. I found in my router's "connected devices" site, that the server has the ip despite my configuration. So I tried the listed wrong IP with: ssh -vv -i ~/.ssh/dropbear_dss_host_key -o 'UserKnownHostsFile=~/.ssh/known_hosts.initramfs' root@ That connects to dropbear but:
  2. Dropbear ignores all public keys other than its own in /etc/initramfs-tools/root/.ssh/authorized_keys (tested with dss - maybe also rsa).
    Solved: Dropbear wants a passphrase for the key, which I do not have. So I tried an empty passphrase. With which dropbear drops to password authentication and wants the root password, that is not set.
  3. Custom hook scripts seem to be partially ignored. These are scripts that worked in older install!

Here is the whole ssh session.

I added my usual public key file to dropbear's known hosts in the server's /etc/initramfs-tools/root/.ssh/authorized_keys and tried to ssh with my usual key. That didn't work.

I added the line GRUB_CMDLINE_LINUX_DEFAULT="ip=" to the server's /etc/default/grup and updated grup. That was meant to fix the IP issue. But that didn't work either.

I'm now thoroughly annoyed and at the end of my patience. Where did I go wrong? Also, is the syntax for the IP settings right because one guide says ::eth0:off and the next says ::etho:none?


There is someone with what seems to be the same problem on 15.04.

Edit 2

I can now connect to the server. Turns out, I had copied the wrong private key to use with dropbear. The error has been corrected in my script above. But adding keys still doesn't work (i.e. to dropbear's authorized_keys file). There's word you need to convert the public keys, that you want to add to /etc/initramfs-tools/root/.ssh/authorized_keys to dropbear's format, but I don't want to spend time searching how. I only tried dss public keys. Maybe dropbear just likes rsa better?

Also I noticed, that custom hook scripts don't seem to work. They are not included in the initramfs' directories but lsinitramfs -l /boot/initrd.img-3.16.0-43-generic lists them as part of the image. The IP settings are still ignored as well. Even if I add GRUB_CMDLINE_LINUX_DEFAULT="ip=" to the grubconfig in /etc/default/grub and update everything.

Edit 3

So it seems that /usr/lib/dropbear/dropbearconvert INPUTFORMAT OUTPUTFORMAT INFILE OUTFILE is the program to convert keys. The FORMAT parameter can be either openssh or dropbear. But it doesn't seem that's the answer on how to add keys to the servers /etc/initramfs-tools/root/.ssh/authorized_keys. The existing key there already is in openssh's public key file format. So adding other openssh-format keys shouldn't be a problem. Yet it is.

  • Now using 17.04. Anyone know, where the authorized_keys file is now located? It doesn't seem to be in /etc/initramfs-tool/root/.ssh/authorized_keys. – con-f-use Apr 23 '17 at 19:52
  • They like to move configuration files around between version numbers just to keep you confused :D They did that to me with plymouth between 14.04 and 16.04. Init-tools had a debug mode I thought to show you what's happening in init-top, init-bottom, local-top, local-bottom I thought? It's been 3 years since I had to monkey around with that stuff so can't be positive I'm remembering correctly. Anyway good luck :) – WinEunuuchs2Unix May 21 '17 at 20:24

It's unclear which known_hosts are troubling you - on the server or on the client. I used the instructions at http://blog.neutrino.es/2011/unlocking-a-luks-encrypted-root-partition-remotely-via-ssh/ on Debian. I am going to paraphrase that page and add some tweak I found useful. Contemporary Debian dropbox packages create all the needed keys on the server at installation time, but the referenced tutorial is so old, that it mentions cases when the keys need to be manually created. YMMV.

A. On the server. As you correctly mentioned, dropbear and OpenSSH keys differ, but are supposedly inter-convertible. The tutorial says that you could create on the server the host keys with:

dropbearkey -t rsa -f /etc/initramfs-tools/etc/dropbear/dropbear_rsa_host_key

In fact, it is a bit harder than that. For me on Debian Jessie, the steps were:

  1. Create a OpenSSH key.

    ssh-keygen -t rsa -b 4096 -m PEM -f bootkey_rsa

  2. Copy it on the server, that is, the computer where you are more likely to have dropbearconvert. There, convert it to dropbear format:

    /usr/lib/dropbear/dropbearconvert openssh dropbear bootkey_rsa bootkey_dropbear_rsa

  3. Stil on the server, login to root, and extract from Dropbear key the public part to the file where boot dropbear looks for it:

    dropbearkey -y -f bootkey_dropbear_rsa | grep "^ssh-rsa" > /etc/dropbear-initramfs/authorized_keys

  4. Update initramfs:

    update-initramfs -u -k all

  5. Cleanup: remove bootkey_dropbear_rsa and bootkey_rsa from server.

Note that the location where the known_hosts is expected by update-initramfs, given above as /etc/dropbear-initramfs/authorized_keys , is flexible, and probably changes from distro to distro. To be sure you put it in the right place, read the source file from /usr/share/initramfs-tools/hooks/dropbear.

The other needed key is created with:

dropbearkey -t rsa -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear

B. On the client you need both kinds of keys, so there is another known_hosts. In the referenced tutorial, the command to connect is:

ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" \
-i "~/id_rsa.initramfs" root@my.server.ip.addr \
"echo -ne \"MyS3cr3tK3y\" >/lib/cryptsetup/passfifo"

One of the keys, id_rsa.initramfs, is the file /etc/initramfs-tools/etc/dropbear/dropbear_rsa_host_key or bootkey_rsa from the server section.

On the client known_hosts, there may be a conflict between the key you already have for the OpenSSH server and the dropbear server you just installed. I temporarily removed from known_hosts the keys for the regular OpenSSH service, connected using the command above (leaving out the -o parameter), got prompted if I trust the host-key, said yes, and got it appended to my known hosts. From there on, you need to move that last line to its own known_hosts (~/.ssh/known_hosts.initramfs in the example above).


Here's how you convert dropbear's key. The startup scripts are a little wonky for me too...

  • Thanks. I'll try /usr/lib/dropbear/dropbearconvert as soon as I have the time. I find it very strange to include this extra step, when it used to work with regular pubic keys. I wonder why the did it and who's idea it was. – con-f-use Jun 27 '15 at 9:13
  • Converting doen't seem the answer here. First of all dropbearconvert only converts private keys. Second, the existing and working key that dropbear autogenerated and added to its authorized_keys file is in openssh foramt so adding other openssh public keys shouldn't be a problem. Yet it is. I have no idea what's going wrong! – con-f-use Jun 27 '15 at 9:53

Boot your SERVER by connecting and unlocking the encrypted partition via your CLIENT

Install mandatory packages (on SERVER)

apt-get install dropbear initramfs-tools busybox

Append your desired public keys into the SERVER's authorized_keys file

Just copy and paste your public key(s) into /etc/dropbear-initramfs/authorized_keys on SERVER

Create the unlock script

Create following script in /etc/initramfs-tools/hooks/crypt_unlock.sh



prereqs() {
  echo "$PREREQ"

case "$1" in
    exit 0

. "${CONFDIR}/initramfs.conf"
. /usr/share/initramfs-tools/hook-functions

if [ "${DROPBEAR}" != "n" ] && [ -r "/etc/crypttab" ] ; then
cat > "${DESTDIR}/bin/unlock" << EOF
if PATH=/lib/unlock:/bin:/sbin /scripts/local-top/cryptroot; then
kill \`ps | grep cryptroot | grep -v "grep" | awk '{print \$1}'\`
# following line kill the remote shell right after the passphrase has
# been entered.
kill -9 \`ps | grep "\-sh" | grep -v "grep" | awk '{print \$1}'\`
exit 0
exit 1

  chmod 755 "${DESTDIR}/bin/unlock"

  mkdir -p "${DESTDIR}/lib/unlock"
cat > "${DESTDIR}/lib/unlock/plymouth" << EOF
[ "\$1" == "--ping" ] && exit 1
/bin/plymouth "\$@"

  chmod 755 "${DESTDIR}/lib/unlock/plymouth"

  echo To unlock root-partition run "unlock" >> ${DESTDIR}/etc/motd


Make it executable:

chmod +x /etc/initramfs-tools/hooks/crypt_unlock.sh

Create a static IP (or skip this step to use DHCP)

Edit /etc/initramfs-tools/initramfs.conf to add (or change) the line:


format [host ip]::[gateway ip]:[netmask]:[hostname]:[device]:[autoconf]

([hostname] can be omitted)

Update initialramfs

update-initramfs -u

Disable the dropbear service on boot so openssh is used after partition is decrypted

sudo update-rc.d dropbear disable


  1. Reboot your server
  2. Connect to your server via ssh root@ [-i ~/.ssh/id_rsa]

Alright everyone, so just in case you didn't find a solution and for anyone else who's pulling their hair out following online tutorials to get this up and running...

All the tutorials I found online say/imply that the file


goes in


when in fact it's supposed to go in


+1 @ceremcem for also showing this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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