Dropbear not using keys I included in FILES directory after sysupgrade

I had to switch from ar71xx to ath79 so I just built my own sysupgrade bin locally and included my configuration files in a FILES directory. All of my other settings were copied fine during the sysupgrade (wireless, firewall, etc) but my ssh key is failing. Worse still, my dropbear settings were copied so I have disabled password authentication by default, which means I have no SSH access. To top it all off, Luci is not starting automatically! I had read online elsewhere that Luci would start automatically on RC1. I lost all three methods of login in one fell swoop. Unfortunately I will not have physical access to this device for months so I was hoping there might be some way to recover here (although I cannot forsee one short of an exploit) and to possibly warn others that may be performing a similar upgrade.

Here is the tree of files I included (taken straight from a backup file).

tree
.
└── etc
    β”œβ”€β”€ config
    β”‚   β”œβ”€β”€ ddns
    β”‚   β”œβ”€β”€ dhcp
    β”‚   β”œβ”€β”€ dropbear
    β”‚   β”œβ”€β”€ firewall
    β”‚   β”œβ”€β”€ network
    β”‚   └── wireless
    β”œβ”€β”€ dropbear
    β”‚   β”œβ”€β”€ authorized_keys
    β”‚   β”œβ”€β”€ dropbear_rsa_host_key
    β”‚   └── dropbear_rsa_host_key-opkg
    β”œβ”€β”€ passwd
    └── shadow

Check the permissions

I don’t know about dropbear, but OpenSSH is picky about the keys, as I recall.

That could be it. Going from the backup archive to my filesystem probably did not maintain the permissions. Dang.

see if your neighbor can run "logmein" on their laptop... ( assuming your config/wifi is legit~active ) it's your knobi hope...

What would LogMeIn gain me? I can still connect to the network fine remotely, all of the other settings were transferred OK. I can still connect remotely to boxes that are wired to the router.

Remote access a LAN machine then you can use it to try to log into the router from the LAN side. I really hope you weren't opening LuCI to the Internet, that is not secure.

That is what I'm doing. LuCI is typically only available on the LAN. I am trying to access it via a computer on the LAN that I am connecting to via remote desktop. It won't even load on the LAN. Do images generated by the imagebuilder not start LuCI by default?

OpenWrt does not generate zips, so you're doing something funky there.

Use sysupgrade to backup and restore settings.

I meant the tar.gz archive.

1 Like

As I very vaguely recall, file permissions past the executable bit don't make it through to the squashfs. (I recall problems with /etc/sudoers not being 400).

It would be possible to chmod them with a script in /etc/uci-defaults (though that may create a copy of the file and not just the metadata on the overlay).

It is all working for me. The local permissions on the dropbear folder are drwx------ and -rw------- on dropbear_rsa_host_key. Everything makes it happily into the image and onto the router.

1 Like

I recently had issues with Dropbear configuration and the Image Builder. Basically, after flashing, router was soft-bricked and had to use failsafe mode to reflash. Eventually I tracked it down to the Dropbear config file authorized_keys placed in files/etc/dropbear.

Previously, the authorized_keys file was being created in the UCI-Defaults script (files/etc/uci-defaults/99-custom) like this:

tee /etc/dropbear/authorized_keys << EOI
ssh-ed25519 <key> user@mail.com
ssh-ed25519 <key> other_user@mail.com
EOI

Then I made the decision to move this into a separate file (because it seems neater), copy-pasting its contents (the two lines between EOI) and saving it as files/etc/dropbear/authorized_keys (next to the host keys). This was the only change I made (at least intentionally).

ssh-ed25519 <key> user@mail.com
ssh-ed25519 <key> other_user@mail.com

I could not find out what exactly went wrong, and I was never able to manually revert this change, spending many hours building and rebuilding images. So I grabbed a fresh copy of the files directory from my backups, and it magically worked again.

Maybe it's a basic file formatting or encoding issue? Problem with newline characters? I don't know. Just wanted to write this over here in case someone bumps into the same problem.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.