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.
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.
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.
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.
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)
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
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.
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 :
Potentially-incompatible changes
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:
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