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 ~]$
Aaron Copley
  • 12,345
  • 5
  • 46
  • 67

2 Answers2

6

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.

Pierre Carrier
  • 2,607
  • 17
  • 28
  • This is close! But, any idea why it reports "Account locked due to 4 failed logins" after only 3? – Aaron Copley Nov 13 '12 at 02: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. – Pierre Carrier Nov 13 '12 at 02: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? – Aaron Copley Nov 13 '12 at 03:04
  • Also, the only changes to a default sshd config are those provided by you. – Aaron Copley Nov 13 '12 at 03:10
  • In /etc/pam.d/system-auth I moved the pam_tally2 auth line below pam_unix and made pam_unix required. This seems to increment the counter as expected! – Aaron Copley Nov 13 '12 at 03:15
  • It behaves correctly on my RHEL system. I really think inspecting /etc/pam.d/password-auth and /etc/pam.d/sshd would help. *Edit:* Good to hear, but surprinsing. I double-checked and get the right behaviour by putting them before pam_unix. – Pierre Carrier Nov 13 '12 at 03:15
  • I will perform a fresh Kickstart tomorrow and see. I would still prefer if it let you know the account was locked after the 3rd failed login. Or before the 4th, but with the correct number of attempts. I can't award the bounty for 10 hours any way. – Aaron Copley Nov 13 '12 at 03:22
  • 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. http://www.openssh.org/faq.html#3.1 – 200_success Nov 15 '12 at 19:41
  • Then the fix would be `PermitEmptyPasswords no` in `sshd_config`. – Pierre Carrier Nov 17 '12 at 03:08
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.

atx
  • 1,281
  • 1
  • 9
  • 25
  • 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. :) – Aaron Copley Nov 13 '12 at 01: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 '12 at 01: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. – Aaron Copley Nov 13 '12 at 01: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 '12 at 02: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. – Aaron Copley Nov 13 '12 at 02:30
  • I'm pretty confused here. Maybe you should update the question with more of an explanation. It looks like Pierre has suggested what you need: Modifying the OpenSSH codebase and using pam_conv to print out a better error message **before** successful log in. – atx Nov 13 '12 at 02:34
  • I don't know what more information I could provide. If you don't understand, setup a test case exactly as described. Either way, @Pierre Carrier's answer looks like it's going to work. I just need to see why the number is wrong. This is likely due to the ordering in password-auth now. – Aaron Copley Nov 13 '12 at 02:50
  • I've tested it and it seems to perform as I expect. – atx Nov 13 '12 at 03:19
  • I think we have different expectations. :) – Aaron Copley Nov 13 '12 at 03:25
  • Looking at the comments you had above with Pierre, it appears this is why I was getting the correct PAM behaviour. My /etc/pam.d/sshd file had the pam_tally2 entry before the pam_unix entry which is inline with what you and Pierre found as well. It looks like this was just a simple case of incorrect ordering in the configuration file. – atx Nov 13 '12 at 04:31