mkinitcpio-dropbear
mkinitcpio-dropbear copied to clipboard
grazzolini
Dropbear doesn't seem to support dss keys anymore.
It seems that dropbear has dropped support for dss keys, probably for security reasons. Here https://bugs.archlinux.org/task/60523 it is mentioned that dropbear recently has improved its security.
Error output: When running mkinitcpio with the dropbear hook, i get following error:
-> Running build hook: [dropbear]
Generating dss host key for dropbear ...
Unknown key type 'dss'
Usage: dropbearkey -t <type> -f <filename> [-s bits]
-t type Type of key to generate. One of:
rsa
ecdsa
-f filename Use filename for the secret key.
~/.ssh/id_dropbear is recommended for client keys.
-s bits Key size in bits, should be a multiple of 8 (optional)
ECDSA has sizes 256 384 521
-y Just print the publickey and fingerprint for the
private key in <filename>.
Suggested fix: remove the dss key generation entirely.
PS: This error described in the above linked archlinux bug report also happend:
-> Running build hook: [dropbear]
Error: Unrecognised key type
Error reading key from '/etc/ssh/ssh_host_rsa_key'
Error: Unrecognised key type
Error reading key from '/etc/ssh/ssh_host_dsa_key'
Error: Unrecognised key type
Error reading key from '/etc/ssh/ssh_host_ecdsa_key'
As described in the bug report, re-creating the openssh host keys with the -m PEM option fixed this. But this is probably not a bug in mkinitcpio-dropbear.
I ran into both issues as well. Thanks for the link to the dropbear bug report!
I don't think this is a bug on this hook. But, if there's a need to change it, please let me know. I have not been using this hook, but he's now part of archlinux's [community] repo.
I don't think this is a bug on this hook. But, if there's a need to change it, please let me know. I have not been using this hook, but he's now part of archlinux's [community] repo.
In the current state, the hook fails as dropbear cannot generate a dss key, does not complete all steps, so you cannot ssh afterwards.
If you remove dss from the line 47 in dropbear_install
for keytype in rsa dss ecdsa ; do
with
for keytype in rsa ecdsa ; do
it works as expected, and you can ssh afterwards
I don't think that removing dss from dropbear is a bug, so I would believe the script should be updated with this simple change.
Regards,
@JeanLucJFr
Indeed the hook itself needs to not check for dss keys anymore. If you are able, can you create a PR for this?
The modification in the PR #9 is indeed cleaner. However, unless I'm mistaken, there was no merge and the modification didn't make it to the arch repository. I understand this package is not used very much, so I'm adding a note in the wiki until this is fixed.
Yes, I need to merge the outstanding PR's to it. I have not used this hook in a while, but I'll try to merge this later and make sure it's working.
I understand this package is not used very much
But there are people using it :) Thanks for efforts anyway, was to lazy to fix this yet... I just created dss keys for dropbear, I think.
I understand this package is not used very much
But there are people using it :) Thanks for efforts anyway, was to lazy to fix this yet... I just created dss keys for dropbear, I think.
Yes, me amongst others :) It's a polite way of pointing out that the bug was not fixed since 6 monthes but that it's understandable... Anyway, the in dm-crypt specialties page of the Arch wiki now points to this thread, so there is a way for people to quickly have remote unlock up&running with dropbear.
Ever since I've switched to tinyssh, I have been using that, hence the reason for not testing this hook properly anymore. I have now set a VM for this purpose and I should soon be able to merge and test the PR's
I don't think you need to test this PR in a VM. The change is minor and straightforward, it just removes a variable and an if-branch. I have tested it multiple times.
Hi,
I tested the change in a VM and all appears well. I was able to boot, ssh and unlock remotely with the suggested change. Please can this hook be released so that others can benefit from your good work :-)
This issue seems to be fixed in PR #9, it would be nice with a new release though as some the Arch community package could then get the source from a more stable source.
@grazzolini did you manage to set up a VM to test this? If so, could you just make a release which would then make it to downstream users? Thanks!
@grazzolini Would you consider adding another maintainer, seeing that you don't use this hook anymore and seem to have little time for maintaining it at the moment?
I may be willing to jump in on this if you're open to another maintainer. I do use this on half a dozen systems still and am an Arch TU to ease that end of things too. I wouldn't be able to do anything serious until mid-December though as I am traveling internationally and won't want to test on remote systems without access to fix them ;-)
