Yet another option is a variant of @Jagadish 's answer: to
strace the ssh daemon.
It has the significant advantage, that we don't need to stop the sshd, what can result a complete lockout if something goes badly.
First, we find the pid of the main sshd process. Here we can see it by executing a
|-sshd,633 -D <-- THIS IS WHAT WE WANT!
| `-screen,638 -r
After knowing, that the pid is 633, we can
strace it, following its children:
strace -p 633 -s 4096 -f -o sux
The result will be that everything what this sshd, and its child processes have done, will be strace-ed into the file named
sux in the local directory.
Then reproduce the problem.
It will have a massive list of kernel call log, which is mostly incomprehensible/irrelevant for us, but not everywhere. In my case, the important thing was this:
6834 sendto(4, "<38>Jan 15 18:49:21 sshd: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84
It was meants, that the sshd tried to log the message User cica not allowed because account is locked - it only couldn't, because logging is not enough verbose for that. But we already know, the pubkey was rejected because the account was locked.
It is not yet a solution - now we need to google, what means a "locked account" in the case of the sshd. It will be most likely some trivial
/etc/shadow wizardry, but the important thing is done - the problem isn't a mysterious, but an easily debuggable/googlable one.
/var/log/auth.logwill tell you why the login is failing.
0700was the answer, but when I did
ssh -von the client side it didn't indicate an error related to why the key wasn't accepted, it just said it was trying password next even though my client sent a public key. How do they expect us to diagnose issues with no error information from the server?