I upgraded my PC to debian bookworm today, and before SSH was working fine on my AP1300, now I get this:
$ ssh root@192.168.x.x
Unable to negotiate with 192.168.x.x port 22: no matching host key type found. Their offer: ssh-rsa
What can I do to regain SSH access?
Do you have LuCI installed? You can change dropbear’s SSH configuration under System > Administration, including ‘Allow root logins with password.’ That should get you logged in so you can optionally generate some new keys if you don’t want to keep using passwords.
If you don’t have LuCI installed, go to the GL.iNet’s GUI, More Settings, Advanced, & follow the prompts to install it.
Yes, I have LuCI installed, but those setting are already as you mentioned, as were working before perfectly, I didn’t change a thing now:
I don’t usually set keyfiles to login to my routers (though I really should). FWIW, the password to the GL.iNet GUI/LuCI should be the same as when connecting via SSH, so it doesn’t look like you’re ‘locked out’ in that regard, fortunately.
Would sshpass help? I expect it’s in Debian’s repos.
sshpass -p < password > ssh root@192.168.8.1
I’m thinking Debian 12 may have changed something in their default settings for SSH. I’d consider commenting out your entry for the router in known_hosts & letting a fresh connection apply it again, as if it was for the first time. You might want to back it up beforehand.
cat ~/.ssh/known_hosts
ssh-keyscan -t rsa 192.168.8.1 >> ~/.ssh/known_hosts
ssh-keyscan -H 192.168.8.1 >> ~/.ssh/known_hosts
# remove
ssh-keygen -r 192.168.8.1
I tried sshpass, did not work.
Then I tried removing the ssh-keygen:
$ ssh-keygen -r 192.168.8.1
no keys found.
How to see which one is from my router in here: ~/.ssh/known_hosts?
Note 192.168.8.1 is the default IP; if you’ve changed it when you last setup your GL-AP1300, you should use that IP instead.
cat ~/.ssh/known_hosts will show all hosts you’ve ever SSH’d into. To see a list of how your Debian host connects to your LAN & the associated route it takes, try:
ip a | grep 192 && route -ne
Your router’s IP is going to be listed in there, somewhere.
I didn’t change the IP it’s 192.168.8.1
Apologies for apparently wasting your time. Try
ssh -oHostKeyAlgorithms=+ssh-rsa root@12.168.8.1
Dropbear on OpenWrt offers an ssh-rsa key, which is rejected by openssh because it is not in it’s list of accepted keys (implicit or in ssh_config). Using this commandline option the config is overruled in you local ssh client. Don’t know if you have to specify it each time, maybe it is stored in known_hosts. (Mijzelf, Apr’22)
[Solved!] SSH: no matching host key type found. Their offer: ssh-rsa
No problem, thanks for the help so far.
Where do I find the “oHostKeyAlgorithms”?
I’m quoting from a SE answer dated 2016:
The client can specify the hostkey algorithm it prefers with the option HostKeyAlgorithms in ssh_config or ~/.ssh/config or on the command line. man ssh_config on your system to see the default HostKeyAlgorithms preference for your version of openssh. The server will use the first key type which is on the client’s list and exists on the server.
If you would prefer to keep the old RSA key challenge, add “-oHostKeyAlgorithms=ssh-rsa” to the command line, or add the line
HostKeyAlgorithms ssh-rsa
to your ssh configuration file(s).
Thanks but I am still not sure what to do.
nano ~/.ssh/config , find the section related to your router’s ssh details, add HostKeyAlgorithms ssh-rsa to it, save, try ssh’ing to the GL-AP1300 again.
Beyond that, ssh -oHostKeyAlgorithms=+ssh-rsa root@192.168.8.1 should still be the quick & easiest.
it worked from another pc, don’t knwo why does not work with my other one…both with debian
No, should I change it?
The IP address needs to be that of the router, or the ‘message’ gets delivered to the wrong address.
always 192.168.8.1, never changed it
OK, worth checking, but now beyond my Pay Grade! Sorry.
np, thanks for the help.
This issue seems to arise from the implementation of Dropbear & changes to OpenSSH. OpenSSH 8.8 was released on 2021-09-26. If it’s 8.8 or better, perhaps reading https://superuser.com/a/1716781 should give a potential permanent resolution, with references the issue from https://www.openssh.com/txt/release-8.8 :
This release disables RSA signatures using the SHA-1 hash algorithm
by default. This change has been made as the SHA-1 hash algorithm is
cryptographically broken, and it is possible to create chosen-prefix
hash collisions for <USD$50K [1]
For most users, this change should be invisible and there is
no need to replace ssh-rsa keys. OpenSSH has supported RFC8332
RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys
will automatically use the stronger algorithm where possible.
Incompatibility is more likely when connecting to older SSH
implementations that have not been upgraded or have not closely tracked
improvements in the SSH protocol. For these cases, it may be necessary
to selectively re-enable RSA/SHA1 to allow connection and/or user
authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
options. For example, the following stanza in ~/.ssh/config will enable
RSA/SHA1 for host and user authentication for a single destination host:
Host old-host HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa
We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
implementations can be upgraded or reconfigured with another key type
(such as ECDSA or Ed25519).
[ emphasis mine ]
[1] “SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust” Leurent, G and Peyrin, T
(2020) https://eprint.iacr.org/2020/014.pdf