On Mon, 24 Nov 2025 12:58:47 +0000 (UTC)
RVP <[email protected]> wrote:
> You'll have to trace the forked child sshd instance...
>
I think that is what "ktruss -d" option does.
> Can you add a line like:
>
> ```
> user.* /var/log/messages
> ```
>
> to /etc/syslog.conf, reboot the system then check what messages `blocklistd'
> logs now?
>
> -RVP
I have already checked this a few days ago on evbarm running
10.1_STABLE for which I did cvs update last week. There is nothing
useful reported in any of the logs.
# grep user /etc/syslog.conf
user.* /var/log/user.log
9.4_STABLE - sshd blocklisting works.
10.1_RELEASE and 10.1_STABLE - sshd blocklisting does not work.
Here is the problem:
If I attempt to log in as a valid user, but provide empty password, so
login eventually fails, then no failure is logged:
rp3# blocklistctl dump -a
address/ma:port id nfail last access
If I repeat the above but with a non-existent user, then failure is
logged:
rp3# blocklistctl dump -a
address/ma:port id nfail last access
10.0.0.2/32:22 1/3 2025/11/24 15:08:34
Is this a bug, or login failures for valid users are for some reason
deliberately not passed by sshd to blocklistd?
Thanks.
