23.05-SNAPSHOT: in fallback mode ssh fails: Bad server host key: Invalid key length

Installing and Using OpenWrt
1

Netgear WAX206 running 23.05 snapshot from yesterday (this commit IIRC).

Edit: confirming, it's r23288-476bf135fc

When in failsafe mode, something about the server's host key makes the SSH client (Fedora 38) unhappy:

$ ssh -v -o UserKnownHostsFile=/dev/null root@192.168.1.1
OpenSSH_9.0p1, OpenSSL 3.0.9 30 May 2023
debug1: Reading configuration data /home/d/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /home/d/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/d/.ssh/id_rsa type -1
debug1: identity file /home/d/.ssh/id_rsa-cert type -1
debug1: identity file /home/d/.ssh/id_ecdsa type -1
debug1: identity file /home/d/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/d/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/d/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/d/.ssh/id_ed25519 type -1
debug1: identity file /home/d/.ssh/id_ed25519-cert type -1
debug1: identity file /home/d/.ssh/id_ed25519_sk type -1
debug1: identity file /home/d/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/d/.ssh/id_xmss type -1
debug1: identity file /home/d/.ssh/id_xmss-cert type -1
debug1: identity file /home/d/.ssh/id_dsa type -1
debug1: identity file /home/d/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.0
debug1: Remote protocol version 2.0, remote software version dropbear
debug1: compat_banner: no match: dropbear
debug1: Authenticating to 192.168.1.1:22 as 'root'
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
Bad server host key: Invalid key length

Note the -o UserKnownHostsFile=/dev/null option, this isn't the client complaining about the host key "changing". It smells to me like the default host key is either completely invalid or falls foul of some of Fedora's (tightening with each release) default crypto policies.

In failsafe mode, shouldn't dropbear default to some on-the-fly generated host key?

Any ideas how to tell ssh "just accept any key/length for now"? I wasn't able to find any option to do that.

Failsafe is essentially inaccessible now that telnet is no longer part of the failsafe config.

2

Contents of the /etc/crypto-policies/back-ends/openssh.config file referenced by the ssh -v output:

Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
MACs hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
GSSAPIKexAlgorithms gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
PubkeyAcceptedAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com
HostbasedAcceptedAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com
CASignatureAlgorithms ecdsa-sha2-nistp256,sk-ecdsa-sha2-nistp256@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-256,rsa-sha2-512
RequiredRSASize 2048
3

Tried all key exchange algos offered by dropbear in failsafe mode, none work:

$ ssh -o UserKnownHostsFile=/dev/null -o KexAlgorithms="diffie-hellman-group1-sha1" root@192.168.1.1
Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,kexguess2@matt.ucc.asn.au
$ ssh -o UserKnownHostsFile=/dev/null -o KexAlgorithms="curve25519-sha256" root@192.168.1.1
Bad server host key: Invalid key length
$ ssh -o UserKnownHostsFile=/dev/null -o KexAlgorithms="curve25519-sha256@libssh.org" root@192.168.1.1
Bad server host key: Invalid key length
$ ssh -o UserKnownHostsFile=/dev/null -o KexAlgorithms="diffie-hellman-group14-sha256" root@192.168.1.1
Bad server host key: Invalid key length
$ ssh -o UserKnownHostsFile=/dev/null -o KexAlgorithms="diffie-hellman-group14-sha1" root@192.168.1.1
Bad server host key: Invalid key length
$ ssh -o UserKnownHostsFile=/dev/null -o KexAlgorithms="kexguess2@matt.ucc.asn.au" root@192.168.1.1
Unsupported KEX algorithm "kexguess2@matt.ucc.asn.au"
command-line line 0: Bad SSH2 KexAlgorithms 'kexguess2@matt.ucc.asn.au'.

BTW what's that kexguess2@matt.ucc.asn.au "algo"?

4

FWIW, this image was built locally with imagebuilder. Is there something "special" to do that seeds such images with a specific default host key that I should have done?

Although, I was able to ssh in the first time, that's how I bootstrapped the whole installation...

5

Booted normally, I can connect to OpenWRT with e.g. ssh -v -o KexAlgorithms="curve25519-sha256" <hostname>. Same algo would not work in fallback.

So somehow the default key (or key auto-generation) on fallback is broken.

Edit: Fallback has workde previously. Is this due to the change to libmbedtls?

6

Is this normal?

# ls -l /rom/etc/dropbear/
-rw-r--r--    1 root     root             0 Jul 23 07:10 dropbear_ed25519_host_key
-rw-r--r--    1 root     root             0 Jul 23 07:10 dropbear_rsa_host_key

versus:

# ls -l /etc/dropbear/
-rw-r--r--    1 root     root           733 Jun 17 14:12 authorized_keys
-rw-------    1 root     root            83 Jun 17 14:10 dropbear_ed25519_host_key
-rw-r--r--    1 root     root          1573 Jun 17 13:57 dropbear_rsa_host_key
7

Maybe a Fedora change.

8

Not sure how I missed that, I swear I searched on github :slight_smile:

This sorts me out partly as a reminder in ~/.ssh/config:

# OpenWRT failsafe https://github.com/openwrt/openwrt/pull/13083
Host    192.168.1.1
        User                    root
        UserKnownHostsFile      /dev/null
        RSAMinSize              1024
9

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.