openssh unix dev - Sep 2003 - unexpected change in "locked account" behaviour

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

On Thu, 25 Sep 2003, Dan Astoorian wrote:
[..]
>
> Is this a known behaviour?
>
This had been discussed a lot over the last few months prior to release.
People were complaining (and semi-rightfully so) that OpenSSH was not
honoring *LK* or each platform's version of it.  So user keys were still
usable even after the account itself was locked.

It was decided that we should honor it.=)

- Ben

Dan Astoorian wrote:
> 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).
In 3.7p1 and 3.7.1p1, if sshd was compiled without USE_PAM,
options.use_pam would still end up being set, even though almost all of
the code that used it was #ifdef'ed out.  The code you quoted still
checked it.
> Is this a known behaviour?
Yes.  The behaviour of 3.7p1 and 3.7.1p1 (ie not checking) when compiled
without PAM was a bug.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.