Skip to content

Commit

Permalink
Debian: Add dropbear instructions
Browse files Browse the repository at this point in the history 
The dropbear-initramfs package can be used to add dropbear SSH support
to the initramfs.  That can be used to remotely unlock the root pool
using the `zfsunlock` script.

Closes #46
Signed-off-by: Richard Laager <[email protected]>
  • Loading branch information
@rlaager
rlaager committed Dec 12, 2021
1 parent db8b190 commit 567524c
Showing 1 changed file with 46 additions and 0 deletions.
46 changes: 46 additions & 0 deletions docs/Getting Started/Debian/Debian Bullseye Root on ZFS.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -720,6 +720,52 @@ Step 4: System Configuration
vi /etc/ssh/sshd_config
# Set: PermitRootLogin yes

#. Optional: For ZFS native encryption or LUKS, configure Dropbear for remote
unlocking::

apt install --yes --no-install-recommends dropbear-initramfs

# Optional: Convert OpenSSH server keys for Dropbear
for type in ecdsa ed25519 rsa ; do
cp /etc/ssh/ssh_host_${type}_key /tmp/openssh.key
ssh-keygen -p -N "" -m PEM -f /tmp/openssh.key
dropbearconvert openssh dropbear \
/tmp/openssh.key \
/etc/dropbear-initramfs/dropbear_${type}_host_key
done
rm /tmp/openssh.key

# Add user keys in the same format as ~/.ssh/authorized_keys
vi /etc/dropbear-initramfs/authorized_keys

# If using a static IP, set it for the initramfs environment:
vi /etc/initramfs-tools/initramfs.conf
# The syntax is: IP=ADDRESS::GATEWAY:MASK:HOSTNAME:NIC
# For example:
# IP=192.168.1.100::192.168.1.1:255.255.255.0:myhostname:ens3
# HOSTNAME and NIC are optional.

# Rebuild the initramfs (required when changing any of the above):
update-initramfs -u -k all

**Notes:**

- Converting the server keys makes Dropbear use the same keys as OpenSSH,
avoiding host key mismatch warnings. Currently, `dropbearconvert doesn't
understand the new OpenSSH private key format
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955384>`__, so the
keys need to be converted to the old PEM format first using
``ssh-keygen``. The downside of using the same keys for both OpenSSH and
Dropbear is that the OpenSSH keys are then available on-disk, unencrypted
in the initramfs.

This comment has been minimized.

Sign in to view

Copy link
@anarcat

anarcat Dec 12, 2021

Contributor

what i typically do instead of this is to have a different set of keys for the two SSHd. if you add both to your known_hosts, you do not get a warning.

This comment has been minimized.

Sign in to view

Copy link
@rlaager

rlaager Dec 12, 2021

Author Member

That's why I marked this as optional. But, in thinking about this more today, does that actually help anything? The risk of sharing keys is that your OpenSSH keys are available on-disk in plaintext. So if someone has access to the disk(s) at rest, they can later MITM your OpenSSH connections while the system is running. But if you trust both Dropbear and OpenSSH keys equally in your known_hosts, you can still be MITMed by someone using the Dropbear keys. A random Dropbear HOWTO that I came across somewhere suggested running Dropbear on a separate port. That would avoid accidentally connecting to the wrong daemon.

This comment has been minimized.

Sign in to view

Copy link
@anarcat

anarcat Dec 12, 2021

Contributor

But if you trust both Dropbear and OpenSSH keys equally in your known_hosts, you can still be MITMed by someone using the Dropbear keys.

That's an excellent point. At work we have a setup where keys are in DNS, but only the encrypted keys. So when we connect to the dropbear daemon we have a warning but still goes through, which helps us detect that yes, we're not in the normal situation and can check if it's normal we're being MITM'd (in a sense).

At home I write the known_hosts keys to different files and have config snippets for unlocking the filesystems, which specify the right known_hosts files.
- Later, to use this functionality, SSH to the system (as root) while it is
prompting for the passphrase during the boot process. For ZFS native
encryption, run ``zfsunlock``. For LUKS, run ``cryptroot-unlock``.
- You can optionally add ``command="/usr/bin/zfsunlock"`` or
``command="/bin/cryptroot-unlock"`` in front of the ``authorized_keys``
line to force the unlock command. This way, the unlock command runs
automatically and is all that can be run.

#. Optional (but kindly requested): Install popcon

The ``popularity-contest`` package reports the list of packages install
Expand Down

0 comments on commit 567524c

Please sign in to comment.