Package Details: mkinitcpio-dropbear 0.0.3-4

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

Dependencies (5)

Required by (2)

Sources (1)

Latest Comments

grazzolini commented on 2016-10-10 19:41

@wgedda
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

Hi,

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

@francoism90
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

@francoism90
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

@ArchangeGabriel
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.

ArchangeGabriel commented on 2015-07-28 10:29

You forgot to update .SRCINFO on latest commit.