Unable to connect via SSH (no matching host key type found)

Attempting SSH login I receive the following error:

Unable to negotiate with 192.168.1.1 port 22: no matching host key type found. Their offer: ssh-rsa

This is despite having System > Administration > SSH Access set as:
Interface: lan (issue persisting even on unspecified)
Port: 22
Password authentication: enabled
Allow root logins with password: enabled
Gatewor Ports: disabled

Creating a key pair and uploading public key to SSH-Keys even produce the same error.

I have rebooted both client and router. Deleted the SSH access user and recreated. Uninstalled Dropbear and re-installed.

My efforts are becoming more and more of a stab in the dark. I just can't see why the error mentions ssh-rsa only when the password authentication / allow root logins with password is enabled in LuCi...

Any ideas welcome, happy to provide further info.

Thank you

1 Like
6 Likes

Thank you, that got me in!

I believe your problem doesn't stem from the configuration of the dropbear server on OpenWRT, but rather your configuration of the SSH client on your client host. The hostkey options have to match (or more correctly, at least one option has to be shared between the dropbear server and the client host's ssh_config).

Two places to look:
/etc/ssh/ssh_config

and
/home//.ssh/config

The latter is writable as a regular user, and supersedes the one in /etc.

Ensure the variable : HostKeyAlgorithms includes 'ssh-rsa' (with no quotes) in the comma-separated list of hostkey algorithms. It will look something like this:

....

HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa
...

Try modifying ~/.ssh/config to include the line above (you actually don't need to include anything but the 'ssh-rsa,' but use your judgement).

Then try again, using just 'ssh root@192.168.1.1' or 'ssh -i rsa_id root@192.168.1.1' and see if it works without the '-oHostKeyAlgorithms=+ssh-rsa' part.

1 Like

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

Your're wrong. This is because OpenWrt uses out of date dropbear version:

'# ssh -V
Dropbear v2019.78

which uses deprecated ssh-rsa algorithm. Today is 2022 but dropbear still 2019 sot that's what we have as a result.

That's an interesting theory. Why do you believe that is the cause? You are not providing a reference. FWIW, on my OpeWRT router:

#> ssh -V
Dropbear v2022.82

In any case, enabling dss is not a good solution. A more permanent solution that does not involve obsolete and insecure algorithms is preferable.

I have an 18.06 box (it is purely for NUT, no internet connection, wifi, or routing functions). It uses: Dropbear v2017.75
and I have no difficulty connecting from various OS's -- including ChromeOS and MacOS Monterey.

I don't think that an old version of Dropbear is responsible for the issue described by the OP. It seems more like the ssh environment they are using on their computer.

OpenWrt 19.07.10 has Dropbear v2019.78

phatgeek
psherman
Which version of OpenSSH do you use?

OpenSSH 8.8 has disabled sha-rsa by default, so anyone running that client would also have difficulty using ssh keys with these old ssh servers: https://www.openssh.com/txt/release-8.8
What else proof do you need?

I use the default ssh version in Mac OS. So for Mac OS Monterey 12.3.1 (this is the most current version available and fully up to date as of this writing)

OpenSSH_8.6p1, LibreSSL 3.3.5

And on Ubuntu 21.10 (with all updates applied as of this moment):

OpenSSH_8.4p1 Ubuntu-6ubuntu2.1, OpenSSL 1.1.1l  24 Aug 2021

Eugene,

Okay, that makes sense. Wait, nope.

What did the OP say that indicates they are using 19.07.10? The current stable release of OpenWRT is 21.02.03. 19.07.10 was four stable releases ago.

I'm curious how you're so certain that the OP is using that particular release. Oh, and you're also certain that the OP is also using OpenSSH version 8.8. Did they say something that would lead you to that belief?

Then finally, what does "by default" have to do with my observation that he can fix this by editing ssh_config (where you go to override default behaviors, including the very settings I pointed them to)?

For having leapt to all those conclusions, you came in a bit hot with "you're wrong."
... which I may well be. It wouldn't be the first time.

19.07.10 was released 20 April 2022. I am not able to use 21.02.3 on TP-Link 1043ND rev.1 because it has not enough memory to operate properly with the latest stable. All release version has kernel upgraded but not all - dropbear updated. But is could be as it is deprecated already.

I did not said te OP uses ossh 8.8 or any other one. So please don't ask me strange questions. I am just talking about modern reality. Because I have the same issue with the same message while trying to co connect by ssh.

How did you do this? Did you use opkg upgrade?

This could be the cause of your issue.

This is strange. As I did not have this issue on Ubuntu 21.10 with OpenWrt 19.07.08.

Was your upgrade using sysupgrade, or did you also use opkg upgrade?

Kernel upgraded by a new openwrt version release but not by opkg. Please, look release notes (https://openwrt.org/releases/19.07/notes-19.07.10):

  • Update Linux kernel from 4.14.167 to 4.14.275

My issue is about deprecated dropbear in 19.07.10. Thats it. And I can't use 22.x or 23.x as they has modern dropbear.

I know that the kernel can only be updated via sysupgrade -- I just wanted to be sure that you didn't try to use opkg upgrade for anything, including dropper.

sysupgrade ofcourse

I would if it would be possible to upgrade dropbear but unfortunately there is now such possibility as I understand.