Bug 1207 (loginsuccess_fail) - sshd does not clear unsuccessful login count on non-interactive logins
Summary: sshd does not clear unsuccessful login count on non-interactive logins
Status: CLOSED FIXED
Alias: loginsuccess_fail
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 4.3p1
Hardware: PPC AIX
: P1 major
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_4_4
  Show dependency treegraph
 
Reported: 2006-07-06 00:52 AEST by John T Mills
Modified: 2006-09-28 19:26 AEST (History)
0 users

See Also:


Attachments
Config.log from openssh 4.3p1, openssl 0.9.8 (644.87 KB, text/plain)
2006-07-06 01:02 AEST, John T Mills
no flags Details
Always call loginsuccess immediately after authentication. (1.31 KB, patch)
2006-07-08 09:28 AEST, Darren Tucker
no flags Details | Diff
Always call loginsuccess immediately after authentication + report previous correctly (1.47 KB, patch)
2006-07-08 10:47 AEST, Darren Tucker
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John T Mills 2006-07-06 00:52:49 AEST
On AIX 5.2 unsuccessful_login_count is incremented by scp because loginsuccess is not run.  ssh will run the loginsuccess but scp does not.     Since lastlog is not reset users can lock themselves out of the system via our max failure checks.
Comment 1 John T Mills 2006-07-06 01:02:51 AEST
Created attachment 1153 [details]
Config.log from openssh 4.3p1, openssl 0.9.8
Comment 2 John T Mills 2006-07-06 01:14:05 AEST
root> ssh posidon "lsuser -R LDAP jtm"
jtm ... unsuccessful_login_count=0 roles=
root> touch /tmp/jtm
root> chown jtm /tmp/jtm
root> scp /tmp/jtm jtm@posidon:/home/jtm/
jtm@posidon's password:
jtm                                                                                   100%   16KB   0.0KB/s   00:00   
root> ssh posidon "lsuser -R LDAP jtm"
jtm ... unsuccessful_login_count=1 roles=
Comment 3 Darren Tucker 2006-07-06 10:38:05 AEST
The problem is not with scp but with sshd (since scp invokes ssh which in turn talks to sshd.

The difference is that loginsuccess is only called as part of the login recording, which only happens for "interactive" logins (ie ones where you get a pty).  You should see the same thing if, instead of scp, you ran something like "ssh yourserver true" and checked the failed login count afterward.

Not sure what to do about it, though.  We can call loginsuccess immediately after successful authentication but that will mean calling it a second time when the pty is allocated.
Comment 4 John T Mills 2006-07-07 22:46:11 AEST
(In reply to comment #3)
 You should see the same thing if, instead of scp, you
> ran something like "ssh yourserver true" and checked the failed login
> count afterward.

This is confirmed.  
Comment 5 Darren Tucker 2006-07-08 09:28:38 AEST
Created attachment 1157 [details]
Always call loginsuccess immediately after authentication.

This patch should fix your immediate problem.

It's probably not ideal as it will result in two audit records for an interactive login (not sure if that matters as I don't use AIX auditing).  I would be interested to hear from anyone who does use AIX's audit facility.
Comment 6 Darren Tucker 2006-07-08 10:47:40 AEST
Created attachment 1158 [details]
Always call loginsuccess immediately after authentication + report previous correctly

Same as patch # 1157 except it reports the previous login correctly.  Please try this one instead.
Comment 7 Darren Tucker 2006-08-30 22:35:47 AEST
Patch #1158 has been applied and will be in the 4.4p1 release.  Thanks for the report.
Comment 8 Darren Tucker 2006-09-28 19:26:26 AEST
With the release of 4.4, we believe that this bug is now closed.  For information about the release please see http://www.openssh.com/txt/release-4.4 .