Hide Forgot
Description of problem: When logging in using ssh two following cases might occur: a) existing user but wrong password, b) non-existing user. PAM/ssh react in these cases by generating audit events USER_LOGIN. In the first case, event is generated correctly. But in the second case, two events are generated: * first event for unknown user (which is ok), * second event for invalid user (which is wrong, confusing). This situation cause aulast to report as follows (for (b) case): # aulast --bad (unknown ssh ::1 Wed Aug 6 17:35 - 17:35 (00:00) (invalid ssh ::1 Wed Aug 6 17:35 - 17:35 (00:00) Version-Release number of selected component (if applicable): audit-2.3.3-4.el7 openssh-6.4p1-8.el7 pam-1.1.8-9.el7 How reproducible: 100% Steps to Reproduce: 1. Empty audit.log (or use checkpoints). 2. Try to log-in via ssh as existing user with wrong password. 3. Try to log-in via ssh as non-existing user. Actual results: Three audit events generated, first is correct, second is correct but the last one is redundant and confusing (invalid user). # ausearch -ts recent -m login,user_start,user_end,user_login ---- time->Wed Aug 6 17:35:09 2014 type=USER_LOGIN msg=audit(1407339309.512:261): pid=27004 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/sshd" hostname=? addr=::1 terminal=ssh res=failed' ---- time->Wed Aug 6 17:35:21 2014 type=USER_LOGIN msg=audit(1407339321.301:266): pid=27009 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct=28756E6B6E6F776E207573657229 exe="/usr/sbin/sshd" hostname=? addr=::1 terminal=ssh res=failed' ---- time->Wed Aug 6 17:35:26 2014 type=USER_LOGIN msg=audit(1407339326.268:272): pid=27009 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr=::1 terminal=ssh res=failed' # aulast --bad root ssh ::1 Wed Aug 6 17:35 - 17:35 (00:00) (unknown ssh ::1 Wed Aug 6 17:35 - 17:35 (00:00) (invalid ssh ::1 Wed Aug 6 17:35 - 17:35 (00:00) Expected results: # ausearch -ts recent -m login,user_start,user_end,user_login ---- time->Wed Aug 6 17:35:09 2014 type=USER_LOGIN msg=audit(1407339309.512:261): pid=27004 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/sshd" hostname=? addr=::1 terminal=ssh res=failed' ---- time->Wed Aug 6 17:35:21 2014 type=USER_LOGIN msg=audit(1407339321.301:266): pid=27009 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct=28756E6B6E6F776E207573657229 exe="/usr/sbin/sshd" hostname=? addr=::1 terminal=ssh res=failed' # aulast # aulast --bad root ssh ::1 Wed Aug 6 17:35 - 17:35 (00:00) (unknown ssh ::1 Wed Aug 6 17:35 - 17:35 (00:00) Additional info: See also https://bugzilla.redhat.com/show_bug.cgi?id=922508#c14. I am not sure if this is a problem in pam or openssh but it is definitely not a bug in audit. Please feel free to change the component if needed.
This audit record is created by sshd directly and not PAM. However I suspect that its generation is triggered by sshd trying to make indistinguishable from the client side whether known or unknown user is trying to login and so I do not expect it to be easily fixed.
There is no requirement to obfuscate the user on unsuccessful logins. You can use acct="unknown" if you prefer to. Currently, acct="(unknown user)" is used which gets hex encoded because of the space in the value and causes it to take up more log space. The major problem is the second entry under acct="(invalid user)", this one should not be sent at all. The AUDIT_USER_LOGIN event should be sent only 1 time and it is the summary decision of all the authentication/account attempts. A couple examples: If 3 password attempts fail, only 1 USER_LOGIN event should be sent saying login failed. If authentication was successful and pam_acct says no because too many sessions/wrong time of day, then only 1 is sent saying login failed. HTH.
This issue has been now reported against RHEL 7 as bug 1158521
Would be acceptable to change this during late rhel-6 release cycle? Could the change break some existing configurations?
The mentioned change would be similar to https://bugzilla.redhat.com/show_bug.cgi?id=1158521#c2
It is acceptable to change this during RHEL6 because what is in RHEL6 is breaking the analysis or perhaps making it harder.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1335.html