There is confusion here between authentication and encryption. The encryption keys are independent of the manner of authentication, and re-keying of the encrypted channel is, as far as I know, independent of the manner of authentication. See https://tools.ietf.org/html/rfc4253#page-23 If you have evidence that re-keying is not performed by reputable SSH implementations, that would be a surprise to many.
As pointed out by @dlakelan the issue is not so much with passwords themselves, but with the strength of those passwords. As long as you're not using deprecated password hashing methods (crypt, md5, ...) and that you're not exposing the password (sending over unencrypted channels, such as not using TLS for your management channel, sharing with other services, ...) then a sufficiently strong password is acceptable for many, including those wearing tinfoil hats. The trick is not to let the tinfoil cover your eyes. "Fluffy" as a password, which is on your Facebook page, is a weak password. There are plenty of reputable articles on either generation and storage of "random" passwords (where the storage is only as good as the encryption used by the "safe" and the password used to access it), or the use of long, but easily remembered passwords. For example (and don't copy this verbatim)
This is probably a decent password to use 4 1 thing?
is a lot better than "Fluffy" or "p@ssword"
That the default configuration for OpenSSH disables many things does not indicate that they are things that should remain disabled. It is simply that when a server comes up in a potentially hostile environment, you want it locked down. That the default firewall for FreeBSD is
65535 deny ip from any to any
doesn't mean that FreeBSD suggests that you shouldn't allow packets. It's just the "safest" default configuration.
Now, let's look at the "single-user OS" statement. First off, hopefully we all agree that you shouldn't be running "user" services on a router. Commercial marketing demands that consumer-grade products provide all kinds of features, like file sharing and whatever they think can sell routers. What really needs to be running on a router/AP and does it need to run as "root"? Looking at my box:
All of those pretty much require privileged access to the system
OK, that one bothers me, but given the structure of how the management interface runs (requiring "root" access to modify the system), I understand why. Would it be better to have uhttpd running as a limited-privelege user but then opening a socket or the like to a privileged process that can modify the system? Meh, still has issues.
I don't run services on my routers, but if you find some in OpenWRT that don't run as limited- or non-privileged user that could, that would be a great project to resolve and open a pull request.
Bottom line, for me:
- Strong, "long" passwords, be they pass phrases or randomly generated are generally sufficient
- Passwords provide the very significant advantage over keyed access in a remote-management situation of not needing to carry all your private keys with you at all times
- If you're going to expose ssh to a hostile network (yes, your wireless should be considered hostile), use of OpenSSH over dropbear is a wise decision
- If you're running LuCI
- Install your choice of luci-ssl-openssl or luci-ssl-mbed
- Modify the uhttpd configuration to only listen on
- Your isolated management interface that isn't bridged to your wireless
- Failing that, only your "inside" interface
- And don't allow "plain" HTTP access, only HTTP-S
- Install your services on something other than your router