Kindle3 can telnet and ssh with pass but cannot with keys

[amar]

Hi all,
I just joined the forum cause recently I have found this community for root and all the goodies like terminal, KOreader, etc.
It's great and I'd like to thank you for making it all so easy and clean

Now one thing is taking me days to solve and still cannot do it, maybe you will be kind enough to help.

I did everything that is required to root, install KUAL, KOreader, launchpad, usbnet, etc.
I can telnet and ssh into Kindle3 Keyboard with dropbear by just pressing Enter instead of a password, next step was to setup authorized_keys file which I did.
First with RSA key and then saw this in ssh -vvv:

debug1: Next authentication method: publickey
debug1: Offering public key: /home/will/.ssh/id_kindle RSA SHA256:3OMCm0BM9fVLwqL141DjgXaibahnP36aVfDMUQZkj88 explicit agent
debug1: send_pubkey_test: no mutual signature algorithm

So I setup ed25519 key and still couldn't login via ssh:

debug1: Offering public key: /home/will/.ssh/kindle_ed25519 ED25519 SHA256:i5ns5vcwnJRPWBoUlXyUyYUVxHHU3TfV139d96HAdtQ explicit agent
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: will@PC RSA SHA256:1Vq1xmJcsGGKDdmUY4MU4yOuobxNIX5mdZixxQRudTE agent
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Offering public key: CaptainDerya's Kindle developer key RSA SHA256:3OMCm0BM9fVLwqL141DjgXaibahnP36aVfDMUQZkj88 agent
debug1: send_pubkey_test: no mutual signature algorithm
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@192.168.2.2's password: 
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
Authenticated to 192.168.2.2 ([192.168.2.2]:22) using "password".
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open

So I don't get it, even though it says that key is ok it then continues to use password but why?

In the /var/log/messages I can find during login:

250610:174245 dropbear[23153]: Child connection from 192.168.2.1:33386
250610:174246 dropbear[23153]: Pubkey auth attempt with unknown algo for 'root' from 192.168.2.1:33386
250610:174314 powerd[2512]: I def:battinfo:cap=100%, mAh=1463mAh, volt=4183mV, current=174mA, temp=80F, bp=4183mV, lmd=1467mAh, cycl=7, cyct=23:
250610:174316 dropbear[23153]: Exit before auth (user 'root', 0 fails): Exited normally

I have all files with the latest version from mostly @NiLuJe page that gathers jailbreak and other apps plus latest certificates that I had to download in order to use KUAL (and I had to update firmware to the latest as well otherwise KUAL wouldn't work as described on forum).

I know that /mnt/us/usbnet/etc/config is responsible for setting up network and ssh options and /etc/
I even try to ssh-add-key to dropbear that defaults a file to /etc/dropbear/authorized_keys which probably wouldn't work and it didn't but at this point I just try to find a solution.

Any information would be appreciated, maybe I just miss something.
I setup IP's in the config file:
Host: 192.168.2.1
Kindle: 192.168.2.2

I'm using Linux to connect to Kindle3 Keyboard.
Usually when I change something and test I try both Dropbear and OpenSSH which is tedious as I have to disconnect, change in KUAL->usbnet toggle, etc.
So this problem affects both Dropbear and OpenSSH.

Possible issues I can think of:
- Not setting my own password on Kindle3 Keyboard but I don't think this is necessary. I tried default ones to login found on forum and python script but they didn't work so I just leave it for the time. Maybe I will want to crack it at some point just to know what Amazon put in. The password is set I just don't know it but this doesn't seem to be an issue here.
- Older version of Dropbear/OpenSSH with older encryption - I kind of mitigated this by creating ed25519 key instead of RSA but maybe I still miss something?
- Maybe current apps are for newer devices that work fine with authorized_keys but Kindle3 Keyboard is not?
- Newest kindle firmware made some changes that are preventing using keys? Don't think so as many people are using it with success.
- Some bug.

If you have any questions or suggestions I'll be happy to try them out.

Best regards,
Amar

[amar]

I tried to edit my post to add some details but I cannot find the "Edit" button.
I tried using some options with no avail as it still asks for password:

ssh -i ~/.ssh/kindle_ed25519 -oKexAlgorithms=+diffie-hellman-group1-sha1 -oStrictHostKeyChecking=no root@192.168.2.2

Again, I can login via telnet and ssh with password easily so device is setup properly.
Also key was copied with:

scp ~/.ssh/kindle_ed25519.pub root@192.168.2.2:/mnt/us/usbnet/etc/authorized_keys

And it looks like this:

[root@kindle root]# cat /mnt/us/usbnet/etc/authorized_keys 
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINSboVb+JERT6orFdr3mo8frs6sIhdSlrhMhZHB/nYbi will@PC

and permissions look right:

-rwxr-xr-x    1 root     root           89 Jun 11 09:02 authorized_keys

I'm using Linux so no windows invisible marks are the issue when I tried to set authorized_keys by hand and usually I just copy the file like above so there is no interference.

[j.p.s]

Nevermind, obviously you have the IP address correct if you are able to login at all.

when you connect with password, what is the output of:

/sbin/ifconfig usb0

[DNSB]

Perhaps the issue lies in the error message?

debug1: Next authentication method: publickey
debug1: Offering public key: /home/will/.ssh/id_kindle RSA SHA256:3OMCm0BM9fVLwqL141DjgXaibahnP36aVfDMUQZkj88 explicit agent
debug1: send_pubkey_test: no mutual signature algorithm

Not sure if you can regenerate the keys but that might be worth a try.

[amar]

Hi j.p.s.
On my PC when I connect the first time the device for Kindle is 'usb0' but when I change for example Dropbear to Openssh (or vice versa) it becomes 'enxee4900000000' until I reboot my PC.

On the kindle it seems to still be usb0 though.
Here's the output:

ssh root@192.168.2.2


Welcome to Kindle!

root@192.168.2.2's password: 
X11 forwarding request failed on channel 0
#################################################
#  N O T I C E  *  N O T I C E  *  N O T I C E  # 
#################################################
Rootfs is mounted read-only. Invoke mntroot rw to
switch back to a writable rootfs.
#################################################
[root@kindle root]# /sbin/ifconfig usb0
usb0      Link encap:Ethernet  HWaddr EE:19:00:00:00:00  
          inet addr:192.168.2.2  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2232 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:293664 (286.7 KiB)  TX bytes:179359 (175.1 KiB)

[root@kindle root]#

[amar]

Originally Posted by DNSB

Perhaps the issue lies in the error message?

debug1: Next authentication method: publickey
debug1: Offering public key: /home/will/.ssh/id_kindle RSA SHA256:3OMCm0BM9fVLwqL141DjgXaibahnP36aVfDMUQZkj88 explicit agent
debug1: send_pubkey_test: no mutual signature algorithm

Not sure if you can regenerate the keys but that might be worth a try.

Hi DNSB,
Yes, that's what I saw the first time when I used default RSA key and that's why I have generated ed25519 key and I think this lines say it's ok:

debug1: Offering public key: /home/will/.ssh/kindle_ed25519 ED25519 SHA256:i5ns5vcwnJRPWBoUlXyUyYUVxHHU3TfV139d96HAdtQ explicit agent
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password

So it looks to me like it is accepting the key but then it moves to next ones like RSA and 3rd one (I have 3 keys in my .ssh) but after checking all those keys it still moves to ask for password. This is what I don't understand.
I tried it on my laptop with fresh, clean system where I put only 1 ed25519 key in my ~/.ssh/ folder (I copied it from my PC) and tried to login again with no success.

[DNSB]

Going off the top of my head here, but the receive packet: type 51 is an authentication failure so it would appear that your public key is not being accepted.

[amar]

Originally Posted by DNSB

Going off the top of my head here, but the receive packet: type 51 is an authentication failure so it would appear that your public key is not being accepted.

This would explain why I cannot get in.
Can you advise what exactly key should I generate for Kindle 3 Keyboard?

I tried default one (RSA 3072), RSA with 4096, ed25519 (default 256), I tried some parameters like described above:

ssh -i ~/.ssh/kindle_ed25519 -oKexAlgorithms=+diffie-hellman-group1-sha1 -oStrictHostKeyChecking=no root@192.168.2.2

I can also post the whole ssh debug output but this is long and not sure if I can spam this forum like that or maybe use some pastebin.

I tried again from my laptop with fresh Mint 22.1 and on Kindle in /var/log/messages this popped up:

250611:190653 dropbear[4579]: Child connection from 192.168.2.1:43320
250611:190653 dropbear[4579]: Pubkey auth attempt with unknown algo for 'root' from 192.168.2.1:43320
250611:190656 dropbear[4579]: Bad password attempt for 'root' from 192.168.2.1:43320 (But we're letting you in because we're a nice Kindle ;))

This would also confirm what you wrote, some wrong 'algo' means I guess 'algorithm'?

[amar]

I kind of found a solution when looking for this 'Pubkey auth attempt with unknown algo for'
After I added these options and changed my key from ed25519 to rsa (3072)

ssh -i ~/.ssh/id_kindle root@192.168.2.2 -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa

I finally could connect properly without giving any password
Actually it works even when I don't specify my key like above so ssh-agent is working fine as well.

I tried also with RSA 4096 and worked as well on both Dropbear and OpenSSH and it's working.
Trying to change to ed25519 didn't work yet but I guess I don't need it anymore or will look for specific options later (I tried '+ssh-ed25519' but there might be a different option).

In the end I checked and with only this one option I can login with my RSA key so this is a solution:

ssh root@192.168.2.2 -o PubkeyAcceptedAlgorithms=+ssh-rsa

Of course one could make it permanent so that there is no need to specify it in the CLI anymore:

vim ~/.ssh/config
        Host k3
        Hostname k3
        User root
        HostKeyAlgorithms ssh-rsa
        PubkeyAcceptedAlgorithms ssh-rsa

The question is though why there is no information on the forum or in the instructions and why is this needed?
Nobody faced this issue or maybe nobody uses ssh keys?

[DNSB]

I suspect this is due to your older Kindle firmware not having support for the newer keys. The SSH-RSA keys were deprecated because they used SHA-1 which is no longer considered secure (this happens in 2022 if my memory serves).

[amar]

I wanted to edit but time expires in 5 minutes so time passed while I was typing - maybe 1h or a day would be a better option to allow people edit threads?

!!! CAUTION !!!
Adding option to Kindle in /mnt/us/usbnet/etc/sshd_config and restarting sshd (via KUAL) breaks ssh completely so no login is possible (tried '+ssh' and 'ssh' without a plus):

PubkeyAcceptedAlgorithms +ssh-rsa

ssh root@192.168.2.2
ssh: connect to host 192.168.2.2 port 22: Connection refused

[amar]

Originally Posted by DNSB

I suspect this is due to your older Kindle firmware not having support for the newer keys. The SSH-RSA keys were deprecated because they used SHA-1 which is no longer considered secure (this happens in 2022 if my memory serves).

Thanks DNSB, I read explanation on some forums but I guess I was asking why nobody here faced this issue since 2022 (already 3 long years
I ask because I saw some posts about Kindle 3 Keyboard so people are still using it.

Anyway, I'm glad that after many days this issue is solved.

[Frogm4n]

When connecting to an older device it's much safer to configure your SSH client as your earlier post did, and not to modify the sshd settings of the old device. It's fairly common to add specific exceptions as-needed to your SSH in the local user config file as you did in your earlier post. If the old device is running an old build of sshd then trying to add crypto that it doesn't support is a giant lift for not much gain.