Bug 712

Summary: ssh does not properly utilize OS specified authentication methods on AIX
Product: Portable OpenSSH Reporter: Ken Robinson <phoenix>
Component: MiscellaneousAssignee: OpenSSH Bugzilla mailing list <openssh-bugs>
Status: CLOSED FIXED    
Severity: normal    
Priority: P2    
Version: -current   
Hardware: PPC   
OS: AIX   
Bug Depends on:    
Bug Blocks: 914    
Attachments:
Description Flags
Move AIX password auth to port-aix.c and use authenticate's reenter
none
Add call to setauthdb() in auth.c
none
Check AIX accounts for SYSTEM=NONE
none
Check for SYSTEM==NONE and auth1 != NONE or SYSTEM. none

Description Ken Robinson 2003-09-24 15:02:21 AEST
AIX allows for the possibility of using other authentication methods to login to
the system in any user definition, which are specified by auth1 and auth2.  An
auth field set to SYSTEM refers to the internal, normal shadow passworded files
on the system.  However, other methods can be specified under
/etc/security/login.cfg, and ssh ignores these.  If one of these methods is in
use, ssh allows a single space, or even any key sequence to allow anyone to
access the account.
Comment 1 Darren Tucker 2003-09-24 19:24:52 AEST
Created attachment 464 [details]
Move AIX password auth to port-aix.c and use authenticate's reenter

Please try this patch.	I've had this in a local tree for a month or so but up
until now I haven't heard of anyone  who actually used that functionality (and
therefore would be able to test it!)  Regular SYSTEM password auth still works
for me (AIX 5.2 tested).

What are you using non-SYSTEM auth for?  It's not an eNetwork firewall is it?
Comment 2 Ken Robinson 2003-09-25 03:44:03 AEST
The above patch does not address the issue.  The system still accepts any
keystroke(s) as an acceptable password for IDs with auth1 set to something other
than SYSTEM regardless of what it should be.  
Comment 3 Darren Tucker 2003-09-25 06:51:42 AEST
Created attachment 465 [details]
Add call to setauthdb() in auth.c

The only other thing I can guess is it needs a call to setauthdb before
authenticate, please try the attached patch (apply to a vanilla 3.7.1p2 tree).
Comment 4 Ken Robinson 2003-09-25 11:12:38 AEST
I applied the second patch to a vanilla p2 tree, and still had the same issue. 
For a non-SYSTEM auth1 userID, SSH allowed any and no key sequence to be
accepted.   The configuration options chosen were that on Darrin Tucker's AIX
SSH page.  
Comment 5 Darren Tucker 2004-01-22 22:09:46 AEDT
This is specific to the account configuration.  Without going into too much
detail, the problem is this:  The accounts were configured with the following
AIX authentication settings:

SYSTEM=none
auth1=somemodule
auth2=none

The problem is sshd uses AIX's authenticate() function, which knows only SYSTEM,
not auth1 or auth2 (AFAIK those are the domain of ckuserID() which is documented
as obsolete, and would be very difficult to support sanely in sshd anyway).

I think the best sshd can do in this case is to detect an unsupportable
authentication configuration (currently my best guess is SYSTEM=NONE && auth1 !=
NONE, feedback wanted!) and deny the login.
Comment 6 Darren Tucker 2004-01-22 23:56:37 AEDT
Created attachment 534 [details]
Check AIX accounts for SYSTEM=NONE

First attempt at testing accounts for SYSTEM=NONE and auth1!=NONE.
Comment 7 Darren Tucker 2004-02-05 19:48:09 AEDT
I think it's too late for this patch to go for the next release.  Since it has
had very limited testing, it has potential for mayhem by denying access to
accounts, simply because they have an unusual but otherwise valid config.

It should probably go in early in the next release cycle.
Comment 8 Darren Tucker 2004-06-28 19:06:23 AEST
Created attachment 668 [details]
Check for SYSTEM==NONE and auth1 != NONE or SYSTEM.

Update to current, move check to after authenticate, make
aix_valid_authentications static.
Comment 9 Darren Tucker 2004-08-29 22:15:34 AEST
I have committed patch #668, and it will be in tomorrow's snapshot.  Because
this patch will (should!) affect only a minority of AIX users I'm keeping the
bug open for now. 
Comment 10 Darren Tucker 2004-11-15 20:15:15 AEDT
Patch #668 was in the 3.9p1 release, closing.
Comment 11 Darren Tucker 2005-03-10 09:07:00 AEDT
With the release of OpenSSH 4.0, these bugs are now closed. For details, see:
http://www.openssh.com/txt/release-4.0