unexpected change in "locked account" behaviour

[Dan Astoorian]

I just ran into what I'd describe as an unexpected side-effect.  I don't
think it's necessarily a bug, and I don't need any assistance in working
around it, but this information might be useful to others for
troubleshooting.

This was using OpenSSH built under Solaris 2.5.1, and running under
2.5.1 or 8.

The symptom was that after upgrading from 3.7.1p1 to 3.7.1p2, some
accounts could no longer log in via ssh using hostbased authentication.

The affected accounts were those with "*LK*" in the shadow file's
password field (and my actual problem was that I had "*LK*" where I
should have had "NP").

I believe the reason for the behaviour change is the change of the
default for options.use_pam.  The reason I find this particularly
strange is that USE_PAM is not even #defined (e.g., UsePam cannot be
specified in sshd_config).

The code which is being affected by the
change is in auth.c:

|         /* check for locked account */
|         if (!options.use_pam && passwd && *passwd) {
|                 int locked = 0;
| 
| #ifdef LOCKED_PASSWD_STRING
|                 if (strcmp(passwd, LOCKED_PASSWD_STRING) == 0)
|                          locked = 1;
| #endif
[...]

I think the current behaviour is more correct than the previous
behaviour, so I haven't filed a bug.

I haven't checked whether there are other places in the code where
options.use_pam has side effects that could be affected by the change in
the default.

If other people who compile OpenSSH without PAM support have similar
problems, this might be helpful to know.

Is this a known behaviour?

Thanks,

-- 
Dan Astoorian               People shouldn't think that it's better to have
Sysadmin, CSLab             loved and lost than never loved at all.  It's
djast at cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican