Bad `authorized_keys` is not reported in non-debug mode

[opk12]

On Debian, -v is not available (no idea if that's deliberate or just an oversight) so, in case of an issue with authorized_keys, you only get Exit before auth from <...>: (user 'michael', 0 fails): Exited normally without a clue.

Digging in the source code, in checkpubkey() in svr-authpubkey.c, the fatal error due to a bad authorized_keys file (line 463) is on a more serious note than the enter checkpubkey above. What about logging it always (not only in verbose mode) and maybe triggering dropbear_exit()? Or checkpubkeyperms() in svr-authpubkey.c might log a precise message.

[mkj]

It should print a message with the filename https://github.com/mkj/dropbear/blob/a1cf9d57252cbd796b083fa1b4d853b86b0aca69/src/svr-authpubkey.c#L606

Checking here:

[3151192] Dec 11 23:09:45 /home/matt/.ssh/authorized_keys must be owned by user or root, and not writable by group or others

[opk12]

Right, I checked again now. dropbear -E -s -F -r ... -w -g -a -p 2222 -P ... warns for permissions of authorized_keys.

It does not warn for non-existent authorized_keys. Please consider if this warrants a warning, because I infer from -s, as a newbie, that there is no other auth method possible besides password and key?

I am otherwise fine with this. Thank you for looking into it.

[mkj]

The problem is that it would print a warning for every user who is just logging in with a password, who doesn't have an authorized_keys file.

[opk12]

But if -s is passed (Disable password logins) and authorized_keys does not exist, the server is unusable?

[opk12]

It is for a non-root dropbear, sorry for not clarifying earlier. The context is my unprivileged container use case described here, so a single-user server + clients who run apps in the same sandbox and the same UID as the server.