dropbear: Reset the pam counters after succefully logging in

[splashwarrior]

Per the pam manual, the user app that is using the pam module,
is the one that should reset the pam counters(tally/tally2).
This fixes cases where dropbear was used to ssh on pam enabled
systems.

[mkj]

I'm not too familiar with PAM credentials, but the docs at http://www.linux-pam.org/Linux-PAM-html/adg-interface-by-app-expected.html section 3.1.8.1 suggest it should be called after the setuid()/setgid() in svr-chansession. Does that work for your case?

What problem does it fix (what're tally/tally2)?

[splashwarrior]

Apologize for the non-descriptive commit message. I will change that.
Background:
I am using a system that uses dropbear to authenticate all incoming SSH sessions. The dropbear app is built on top of the linux pam modules. For each unsuccessful attempt PAM maintains a counter(referred as tally/tally2 counter). Once it crosses a predefined max_attempts, that particular user is blocked for a certain timeout period. However, when the user enters the correct password, this counter should reset back to zero. This is what the pam_setcred call does, it tells the pam module to set the correct permissions and reset the counter. I believe svr-authpam.c is the right place to make this as soon as the password has been authenticated.
I think your suggestion may work, but I havent tried that.

[joseph-reynolds]

Thanks for this change. I think this patch is close to what I need. I am using PAM with the pam_tally2 module and with expired passwords (https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2019q4/002174.html) and I am seeing a small bug:

When an SSH client connects to the Dropbear server with a correct username and password, the pam_tally2 counter is incremented for that user, then pam_acct_mgmt() detects the password is expired (rc == PAM_NEW_AUTHTOK_REQD), so Dropbear sends a message back to the client that the password needs to be changed. At this point, as far as the Dropbear SSH server, the transaction is over. The problem is that the tally counter has been incremented even though the client has done nothing wrong, so the user is one tally closer to being locked out of their account. That seems wrong to me, and I want to reset the tally in this case.

I think the flow in svr-authpam.c could be like this (in addition to your patch):

if ((rc = pam_authenticate()) ...) {
    ...
}
if ((rc = pam_acct_mgmt()) ...) {
    /* MY IDEA: */
    if (rc == PAM_NEW_AUTHTOK_REQD)
        rc = pam_setcred(pamHandlep, PAM_ESTABLISH_CRED);
    ...
}
...
/* successful authentication */
/* THE PATCH FROM THIS PULL REQUEST: */
rc = pam_setcred(pamHandlep, PAM_ESTABLISH_CRED);
...

However, I am also not familiar with PAM practices or with dropbear flows.