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 .zip to my filesystem probably did not maintain the permissions. Dang.

Any idea about Luci? Is it supposed to start automatically on reboot? I assumed that it did. If I can get in via Luci I may be able to fix this yet. Would a hard reboot possibly start it (maybe it needs to reconfigure on first boot)? If so I can ask my neighbor to power cycle my outside breaker.

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