Package Details: mkinitcpio-dropbear 0.0.3-4

Git Clone URL: (read-only)
Package Base: mkinitcpio-dropbear
Description: Archlinux mkinitcpio hook to install and enable the dropbear daemon in early userspace
Upstream URL:
Keywords: dropbear mkinitcpio network ssh
Licenses: GPL3
Conflicts: mkinitcpio-tinyssh
Submitter: grazzolini
Maintainer: grazzolini
Last Packager: grazzolini
Votes: 16
Popularity: 0.000125
First Submitted: 2015-07-11 02:45
Last Updated: 2016-10-21 11:21

Dependencies (5)

Required by (2)

Sources (1)

Latest Comments

1 2 Next › Last »

polslinux commented on 2018-03-18 19:48

Hello, could you please change the hook to give the user the possibility to choose another port rather than the default? :)


grazzolini commented on 2017-11-27 21:27


Well, you asked the question and answered it yourself. I like when users do this ;-).

To be clear, yes, the root_key is used for authenticating the client connecting *to* the dropbear server in the initramfs. There's no SSH client on the initramfs. As far as I know, the dropbear project (and tinyssh), only provide a ssh server, not client, in the first place.

I could probably rename it to resemble more OpenSSH's authorized_keys file. But the idea here is that the /etc/dropbear/root_key is just a staging file that is copied to the initramfs.

probackup-nl commented on 2017-11-27 16:19

I'm still not sure whether I do understand /etc/dropbear/root_key (and I don't know that LUKS is).

Quote: /etc/dropbear/root_key is used for **client** authentication.

Does that mean: during the automated boot process a connection to a remote SSH host is made to retrieve information from, and no password is asked?

When building a system recovery initramfs (not regular boot) I only want dropbear to be present as SSH **server** (not as SSH client), can I then completely skip /etc/dropbear/root_key file?

I don't think so, '/etc/dropbear/root_key' is like '/root/.ssh/authorized_keys'

grazzolini commented on 2016-10-10 19:41

It only generates the keys *if* you don't have OpenSSH on the system. If you have, and if you ran OpenSSH at least once (it creates it's own keys), then mkinitcpio-dropbear will convert those keys and use them.

If you don't have OpenSSH installed or you didn't ran it yet, when generating the initramfs, the hook will create *new* keys, that will certainly differ from the OpenSSH ones.

The *public key* that should be present on /etc/dropbear/root_key is the key used for *client* authentication, not server. In other words, this is the key used to authenticate as root so you can type your luks password, for example.

Also, keep in mind that the hook won't overwrite keys. If you initially created your own (no OpenSSH) and later installed OpenSSH, you will need to remove the existing keys under /etc/dropbear/dropbear_*_host_key.

wgedda commented on 2016-10-10 18:37


mkinitcpio-dropbear generates private RSA, DSA and ECDSA SSH keys when mkinitcpio is executed. Can anyone explain why? As I understood from the source code (see Upstream URL) the keys cannot be used as long as you do not derive public keys from the private ones and add them to /etc/dropbear/root_key and then generate initramfs again. Is this right?

Regards, Patrick

grazzolini commented on 2016-08-29 04:13

I don't see how something that is happening on the console would affect your ssh session. When you login through ssh it spawns a different shell over a pts. This seems to be something very specific. Try booting with break=premount so it will give you a shell into the initramfs so you can try to debug it further.

francoism90 commented on 2016-08-28 13:43

Hi grazzolini, thanks for your reply. :)
Example: a DVB USB-stick was displaying errors at the passphrase screen, because of missing code in the module, resulting in 'lose focus' for the password field.

You could try trigger this issue by inserting an USB-stick on the passphrase screen and then trying to connect over SSH to the machine.

grazzolini commented on 2016-08-28 12:17

Can you please provide more information? I'm able to boot using the quiet flag and also without it. Which errors are present?

francoism90 commented on 2016-08-28 11:43

Hi grazzolini,

As kernel parameter I'd to set quiet flag, otherwise (potential) errors block the unlock process.
For some reason this is only needed in the latest versions, should this be recommend in the Wiki?

Thanks for your work. :)

grazzolini commented on 2015-07-28 14:13

Than you. I've updated it now. I was experimenting with hooks to automatically create and commit the SRCINFO file. So far the experiment failed.