dropbear won't start with ED25519 hostkey
lez opened this issue · comments
I compiled dropbear with make -j 16 MULTI=1 SCPPROGRESS=1 'PROGRAMS=dropbear dropbearkey dropbearconvert dbclient ssh scp' NOSYSHOSTKEYLOAD=1 WRITEOPENSSHKEYS=1
The following command throws an error:
/usr/sbin/dropbear -E -F -r /etc/dropbear/dropbear_ed25519_host_key -p 2222
[6955] Jul 12 16:35:48 Early exit: String too long
architecture:
Linux host 4.9.80 #1 SMP Wed Jul 4 17:28:01 CEST 2018 armv7l GNU/Linux
the key has been generated with dropbearkey -Z openssh -t ed25519 -f dropbear_hostkey_ed25519
Any ideas why this might happen?
Thank you for reporting this bug!
This looks like a bug in drobearkey. If I generate an ssh-ed25519 key with OpenSSH (ssh-keygen -t ed25519 -f openssh_hostkey_ed25519 -P '' -C blah), then dropbear works.
FYI I'm getting a different error message with dropbearmulti compiled with c.sh:
[126377] Jul 12 20:13:54 Failed loading hostkey /tmp/dropbear_ed25519_host_key
[126377] Jul 12 20:13:54 Early exit: No hostkeys available. 'dropbear -R' may be useful or run dropbearkey.
I'll investigate and fix dropbearkey later.
I was able to reproduce this bug (String too long) on both i386 and amd64 when compiled with your make command. When I compile with c.sh, it works. I'll take a deeper look later.
Your make command is missing an OPENSSHHOSTKEYLOAD=1. To fix it, recompile it like this:
make clean
make -j 16 MULTI=1 SCPPROGRESS=1 'PROGRAMS=dropbear dropbearkey dropbearconvert dbclient ssh scp' NOSYSHOSTKEYLOAD=1 WRITEOPENSSHKEYS=1 OPENSSHHOSTKEYLOAD=1
The fix works for me.
I've just improved the error reporting (last commit: a9f901e ). Now instead of String too long, it reports that an OpenSSH hostkey was detected, and make OPENSSHHOSTKEYLOAD=1 is needed to load it.
Thanks! I updated my make command.
I am now getting the new error message saying No hostkeys available. Generate them and specify them as 'dropbear -r ...'. for the original command line (which includes -r)
If I specify an additional RSA hostkey with -r dropbear_rsa_host_key, the server starts and the rsa key can be ssh-keyscan-ned from the client.
It seems that it doesn't load the ED25519 key nor it reports an error message about it.
I have tried it with keys generated with both dropbearkey and ssh-keygen, same results.
I wonder what could be different in our setups that might cause mine to silently ignore the ed25519 key.
I can't reproduce this, please copy-paste the full transcript (command-lines to generate the keys, command output, dropbear command line, command output). Also run strace -e open dropbear ..., and copy-paste the full output.
ssh-keygen
Openssh on an arch linux (OpenSSH_7.7p1, OpenSSL 1.1.0h 27 Mar 2018)
$ ssh-keygen -t ed25519 -f openssh_hostkey_ed25519 -P '' -C blah
Generating public/private ed25519 key pair.
Your identification has been saved in openssh_hostkey_ed25519.
Your public key has been saved in openssh_hostkey_ed25519.pub.
The key fingerprint is:
SHA256:SdwGDJEWIpRVLNqSTtRWLZ5unS7j8p2Pho/fdgvG49w blah
The key's randomart image is:
+--[ED25519 256]--+
| .o+o+*B. |
| o.+.=.oo |
| . = + oo o |
| = . o. o |
| o . . .S. |
| . o o. |
| . o = |
| . +ooB.+. |
| ++**o=.E. |
+----[SHA256]-----+
The generated key openssh_ed25519_host_key
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACCTFZPZ7p0idBTGGZjVhRmSCAZb6Ha0muU6dBO/wFnc0QAAAIiI5TYTiOU2
EwAAAAtzc2gtZWQyNTUxOQAAACCTFZPZ7p0idBTGGZjVhRmSCAZb6Ha0muU6dBO/wFnc0Q
AAAED9fBLb5/6OiCHGrewZTl0CimB3nlA5VPAQGBV8W9ud0ZMVk9nunSJ0FMYZmNWFGZII
BlvodrSa5Tp0E7/AWdzRAAAABGJsYWgB
-----END OPENSSH PRIVATE KEY-----
dropbear
# strace -e open /usr/sbin/dropbear -r /etc/dropbear/dropbear_ed25519_host_key -F -E -m -p 2222 -P /var/run/dropbear2.pid
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/libutil.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/etc/dropbear/dropbear_ed25519_host_key", O_RDONLY|O_LARGEFILE) = 3
open("/etc/dropbear/dropbear_ed25519_host_key", O_RDONLY|O_LARGEFILE) = 3
open("/etc/localtime", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[9236] Jul 19 11:22:02 Early exit: No hostkeys available. Generate them and specify them as 'dropbear -r ...'.
+++ exited with 1 +++
Thank you for providing more details!
I still can't reproduce this bug with the latest pts-dropbear and with the private host key you've provided:
$ git clone https://github.com/pts/pts-dropbear
$ cd pts-dropbear
$ git rev-parse HEAD
dcabc45f4d9c8492376c93ae4461e221d9697a79
$ ./configure
...
$ make NOSYSHOSTKEYLOAD=1 OPENSSHHOSTKEYLOAD=1
...
$ cat >openssh_ed25519_host_key <<'END'
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACCTFZPZ7p0idBTGGZjVhRmSCAZb6Ha0muU6dBO/wFnc0QAAAIiI5TYTiOU2
EwAAAAtzc2gtZWQyNTUxOQAAACCTFZPZ7p0idBTGGZjVhRmSCAZb6Ha0muU6dBO/wFnc0Q
AAAED9fBLb5/6OiCHGrewZTl0CimB3nlA5VPAQGBV8W9ud0ZMVk9nunSJ0FMYZmNWFGZII
BlvodrSa5Tp0E7/AWdzRAAAABGJsYWgB
-----END OPENSSH PRIVATE KEY-----
END
$ ./dropbear -r openssh_ed25519_host_key -F -E -m -p 2222
[124806] Jul 19 15:34:01 Not backgrounding
... (continues running)
I'm happy that you are taking the time to tackle this down.
On Monday I can give you ssh access to a raspberry pi where the bug shows itself.
Alternatively, if you are open to that, we would gladly invite you to our office (in north Buda) to have a closer look.
(we can talk over the details over keybase; my handle is 'lez' over there)
In the meantime, please run the same commands (starting with git clone), and copy-paste the output to this issue.
It turns out that the bug comes out if I remove
#define DROPBEAR_DSS
from options.h
Thank you for reporting and debugging this! Fixed in 18cb19b.