7

I am using pam_tally2 to lockout accounts after 3 failed logins per policy, however, the connecting user does not receive the error indicating pam_tally2's action. (Via SSH.)

I expect to see on the 4th attempt:

Account locked due to 3 failed logins

No combination of required or requisite or the order in the file seems to help. This is under Red Hat 6, and I am using /etc/pam.d/password-auth. The lockout does work as expected but the user does not receive the error described above. This causes a lot of confusion and frustration as they have no way of knowing why authentication fails when they are sure they are using the correct password.

Implementation follows NSA's Guide to the Secure Conguration of Red Hat Enterprise Linux 5. (pg.45) It's my understanding that that only thing changed in PAM is that /etc/pam.d/sshd now includes /etc/pam.d/password-auth instead of system-auth.

If locking out accounts after a number of incorrect login attempts is required by your security policy, implement use of pam_tally2.so.

To enforce password lockout, add the following to /etc/pam.d/system-auth. First, add to the top of the auth lines:

auth required pam_tally2.so deny=5 onerr=fail unlock_time=900

Second, add to the top of the account lines:

account required pam_tally2.so

EDIT:

I get the error message by resetting pam_tally2 during one of the login attempts.

user@localhost's password: (bad password)
Permission denied, please try again.
user@localhost's password: (bad password)
Permission denied, please try again.

(reset pam_tally2 from another shell)

user@localhost's password: (good password)
Account locked due to ...
Account locked due to ...
Last login: ...
[user@localhost ~]$

2 Answers 2

6
+250

You also need ChallengeResponseAuthentication yes in /etc/ssh/sshd_config.

To display the error, pam needs a conversation function.

This option tells ssh to provide a more complete PAM conversation function, which covers amongst other things providing output and asking for arbitrary input (instead of just being handed over a password by sshd).

Edit: You'll want PasswordAuthentication no to make sure the password input always goes through this PAM conversation.

9
  • This is close! But, any idea why it reports "Account locked due to 4 failed logins" after only 3? Nov 13, 2012 at 2:43
  • You probably hadn't disabled PasswordAuthentication, had you? It would have then gone through the PAM stack twice. Edit: if not, I'd like to review your /etc/pam.d. Nov 13, 2012 at 2:54
  • PasswordAuthentication is set to no. (Service restarted.) I don't think it's going through twice, what you're describing should get faillog incremented to 6. This just seems as though it's incrementing faillog before authentication. The auth line for pam_tally2 should go after pam_unix now to avoid this? Nov 13, 2012 at 3:04
  • Also, the only changes to a default sshd config are those provided by you. Nov 13, 2012 at 3:10
  • 2
    I believe sshd first attempts to log in using an empty password no matter what, so that the client would be spared from seeing a password prompt if the account has no password. That would account for one failed attempt. openssh.org/faq.html#3.1 Nov 15, 2012 at 19:41
0

Unfortunately what you're after is not available. OpenSSH will only allow or deny authentication. It's not going to give an attacker or a clumsy user know any further information and this is standard behaviour. PAM has no knowledge of the network communication that OpenSSH or any other application-specific behaviour it's using. It's just a bunch of modules for authenticating with.

Further to this, pam_tally2 doesn't provide any kind of user-defined error message directive, so you can only rely on what's in your system log anyway.

One method you can look into is modifying the OpenSSH codebase (not too difficult), but this is out of the scope of this question.

10
  • I'm not asking for a user-defined error, rather trying to get the built-in error to function as intended. (See my edit where it is possible--just not functioning as desired.) OpenSSH has nothing to do with allowing or denying authentication, that is handed off to PAM. Could you support your claim that it is a risk to tell an attacker why they will never be able to login to the account? I'd be interested in reading further. Lastly, for a +250 bounty, I'd say not much is outside the scope of the question. :) Nov 13, 2012 at 1:24
  • Yes, you are right in that OpenSSH only passes off the authentication to PAM. I'm sorry if I didn't convey that properly. I seem to get the error message 'Account locked due to 4 failed logins' after resetting the user's tally. So I'm not sure what else you're after. As for the example of the claimed risk I made: Suppose we have deny=3 set with pam_tally2 and an attacker is trying several username and password combinations. If they know that account X is now locked, they can confirm its existence. However this isn't a problem if we report that for non-existent accounts too.
    – atx
    Nov 13, 2012 at 1:36
  • Ok, I see where some environments may not want to leak usernames externally this way. In my case, this isn't a concern as there is external no access. Nov 13, 2012 at 1:57
  • There are other things to note too: internal attackers, knowing that you lock accounts results in less brute-forcing and trying other attack vectors, etc. However in your case it does seem less relevant. I think what you want is already solved? You can get the locked account error message to show, right?
    – atx
    Nov 13, 2012 at 2:23
  • I only see the error message under specific circumstances. If I reset faillog during authentication process of a locked account. After the first (or second) failed attempt, I reset the faillog and the user enters the good password. Authentication succeeds and previously suppressed messages display. It needs to display to the user when authentication has failed for that reason. Nov 13, 2012 at 2:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .