Mova P10 Ultra does not accept new ssh key #2437
-
Are you already using Valetudo?Yes, just started Your questionsA few days ago my Mova disappeared from my network and I was unable to find it again. I ended up performing a factory reset and was able to successfully root the bot again but now I'm getting stuck when I try to SSH in. I keep hitting a wall and being requested to provide a password. The troubleshooting I've tried leads me to believe that perhaps I should be using the same keys from the first time I rooted the bot? Which if that's the case then past me royally fcked current me bc I cannot for the life of me find the USB that had the backup. So I'm curious, has anyone encountered this before? Have I locked myself out of the bot? I am new to this but really trying to learn and grow here so thanks in advance for any thoughts. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Yes, this is a footgun of the not-quite-ideal implementation of ssh keys we built back when initially testing + to allow adding new keys without reflashing There are actually three locations where the authorized_keys file is stored
On boot, If 2 is empty, 1 is being copied to 2. After that, 2 is being copied to 3. There is no special logic in place that would add new keys from 1 to 2, so because 2 exists, the now-different 1 from your new firmware image is never being copied to 2. So yes, use the old key, delete Additionally, there is also a passwordless rootshell on the UART as another way in. |
Beta Was this translation helpful? Give feedback.
Yes, this is a footgun of the not-quite-ideal implementation of ssh keys we built back when initially testing + to allow adding new keys without reflashing
There are actually three locations where the authorized_keys file is stored
/authorized_keys- which is part of the rootfs and thus gets flashed, but also is read only/mnt/misc/authorized_keys- which is not being flashed, but r/w and persistent/tmp/.ssh/authorized_keys- which is the HOME dir where dropbear expects the keyfile + is als a tmpfsOn boot, If 2 is empty, 1 is being copied to 2. After that, 2 is being copied to 3.
So if you want changes to persist, you need to modify 2.
There is no special logic in place that would add…