SSHD 3.7.1p2 on HP-UX

[Michael Steffens]

Eric Cunningham wrote:
>> Could you please check what sshd in debugging mode "sshd -ddd" reports
>> about aging?
> 
> 
> <snip>
> 
> debug3: allowed_user: today 12325 sp_expire -1 sp_lstchg -1 sp_max 0
> User eric password has expired (password aged)
> 
> <snip>
> 
> 
>> Could you please also check what
>>
>>   /usr/lbin/getprpw <username>
>>
>> reports about the account being rejected?
> 
> 
> root:#-> /usr/lbin/getprpw eric
> uid=5928, bootpw=NO, audid=10, audflg=1, mintm=-1, maxpwln=-1, exptm=-1, 
> lftm=-1, spwchg=-1, upwchg=Fri Mar 31 15:18:43 2000, acctexp=-1, 
> llog=-1, expwarn=-1, usrpick=DFT, syspnpw=DFT, rstrpw=DFT, nullpw=DFT, 
> admnum=-1, syschpw=DFT, sysltpw=DFT, timeod=-1, slogint=Tue Sep 30 
> 08:26:48 2003, ulogint=Thu Sep 25 14:03:12 2003, sloginy=pts/ta, 
> culogin=-1, uloginy=-1, umaxlntr=-1, alock=NO, lockout=0000000
> 
> For kicks, after this, I reset my password and tried again.  It worked. 
> I hadn't thought my password was expired...I had no trouble logging in 
> via non-ssh methods (ie, @console, telnet).  Thanks very much for the 
> clues!
> 
> I'm a little embarrassed but grateful...

Not so fast :)

I would predict that login will fail again tomorrow, as it does for Jan,
and with your info I probably learnt why :)

sshd got "sp_max 0" grom getspnam. This happens if aging policies for
the user are set to *disable* aging!

Now let's look at what auth.c does:

     if (spw->sp_max != -1 &&
         today > spw->sp_lstchg + spw->sp_max) {
             logit("User %.100s password has expired (password aged)",
                 pw->pw_name);
             return 0;
     }

It expects the value -1 for disable aging. If sp_max happens to be zero
instead, the aging calculation will succeed non-expired only on the
day the password was last changed.

Manual page getspent(3C) states

   If the fields corresponding to sp_min, sp_max, sp_lstchg, sp_warn,
   sp_inact, sp_expire, or sp_flag are not specified in the entry, they
   default to -1.

Ooops! Should getspnam have returned -1 instead? The field corresponding
to sp_max in the /tcb database is u_exp, and for a user with aging
disabled the record reads like

dummy:u_name=dummy:u_id#104:\
         :u_pwd=*************:\
         :u_auditid#445:\
         :u_auditflag#1:\
         :u_minchg#0:u_exp#0:u_life#0:u_succhg#1064822018:\
         :u_pw_expire_warning#0:u_pswduser=dummy:u_pwchanger=roottmp:u_suclog#1064819726:\
         :u_lock@:chkent:

So far getspnam does what it is supposed to do, because u_exp does
exist with value 0.

Does it need to? modprpw(1M) claims

   No aging is present if the following 4 database parameters are
   all zero: u_minchg, u_exp, u_life, u_pw_expire_warning.

and disabling a user's aging (for example via SAM) does exactly
that.

Now, how to detect this properly with struct spwd data? All of the
fields above besides u_life do have corresponding swpd fields.

(u_life is password lifetime, similar to expiration time, but
admin intervention required to unlock if lifetime is exceeded.)

So what I would propose for HP-UX trusted systems is to consider
aging disabled

  - either when sp_min, sp_max, and sp_warn are all zero

  - or when getprpwnam returns u_minchg, u_exp, u_life,
    u_pw_expire_warning to be all zero.

The first looks like a less intrusive modification, but would
not detect u_life to be non-zero.

The second looks like password aging for trusted systems should
not be done using shadow data at all. But please do not
eliminate shadow for HP-UX entirely, because there is native
/etc/shadow shadowing available on 11.11 :)

Cheers!
Michael