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

dropbear/src/svr-authpubkey.c

Line 606 in a1cf9d5

dropbear_log(LOG_INFO, "%s must be owned by user or root, and not writable by group or others", filename);

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.