Public key authentication defeats passwd age warning.

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Greetings all,

Havin' some trouble.  Thought y'all might be able to help me out.
I went and got the latest-n-greatest (3.9p1-1) sources (in RPM form)
from  After some putzin' around with thisnthat, I've
got it mostly working.  However, the problem I'm having is that if I
set up the public/private key pair to work without a passwd, and also
set up expiring passwds, the warning that is supposed to be posted
on login that ``your passwd will expire in xyz days'' stops working.

The only things that I changed from their defaults were:

1) I put the config files in /etc/ssh instead of in /usr/etc/ssh by
way of the .spec file before compiling.

2) I changed these two entries from their defaults in the sshd_config
file of the server to which I'm trying to connect:

2a) ChallengeResponseAuthentication I changed to no

2b) UsePAM I changed to yes

UsePAM I changed because that seemed to make passwd aging work.  I.e.
when set to its default of ``no'', even if the lUser logging in was
WAY past the expiration their passwd, it would still let them in as
if nothing was wrong.  When I changed it to ``yes'' the lUser is
challenged to reset their passwd immediately on login, as is supposed
to be the case.  The other one, I just thought it was a good idea
based on the comments in the config file...

Changing ChallengeResponseAuthentication back to yes had no effect.
No warning is issued during that warning window.

It took much reading and playing around before I realized that if I
removed my public key from the destination machine (so that I would
be prompted for a passwd), then the warnings would appear as they
are supposed to.

Sounds like a bug to me...  Anyone have any ideas?  Is there a secret
handshake I'm missing somewhere?  Heaven knows SSH is full of them
(as it should be given the nature of its task).

Oh, yeah:  The OS in question is a highly modified RH 7.2ish system.
We replace bits and pieces of it hither and yon as we find that this
piece has a security hole or that piece has a bug, etc.


To reply by mail, remove all lower case letters in my return address

Re: Public key authentication defeats passwd age warning.

Quoted text here. Click to load it

In OpenSSH's native password support, password expiry is only checked
during password authentication, and the warning is generated as part of
that check (auth_shadow_pwexpired in auth-shadow.c).

In PAM's world view, password expiry is done as part of the account checks
(ie pam_acct_mgmt) which sshd must check for all auth types (since it
has no idea what critera PAM might use for those checks).

It would be possible to generate the messages for non-password auths too
but I'm not sure it makes sense.  If you're not using the password at all,
is it relevant that it's expired?  And what do you do if it is?  Deny the
login even though the credentials used for the authentication (ie the
public key) are perfectly fine?  Or generate a message of the form "your
password expired X days ago"?

Darren Tucker (dtucker at
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.

Re: Public key authentication defeats passwd age warning. (Darren Tucker) writes:
Quoted text here. Click to load it

the basic premise of passwords is that they are shared-secrets and
vulnerable to all sorts of attacks ... where obtaining knowledge of
the passwords can lead to exploits. password expires supposedly bounds
the duration of any such exploits.

public keys can be substituted in place of passwords ... put them in
the table entry and identify digital signature as the method of
authentication (instead of password compare). if the system
authentication file supported that ... then ssh could stuff the public
key there in lieu of password ... instead of needing its own table.

since knowledge of public key isn't subject to the same sort of
exploits as passwords ... the requirement for frequent changes is
severely mitigated as means of bounding (undiscovered) exploits.

there are however possibly two completely different issues here

1) confusing that digital credentials are equivalent to public key.
public keys can easily be done like ssh ... which just registers the
authentication material ... however, it registers a public key for
performing authentication instead of registering a password for
authentication & maintains the same business process. because of the
vaguries of current "password" oriented authentication files ... ssh
resorts to its own registration file. note that this is a completely
different business process for authentication material than the
typical digital credential business process. while the ssh-like method
preserves the business process for the relying party to register the
authentication material ... the digital credential model originated so
that the registration process could be outsourced to 3rd parties.

2) there are still exploits on public/private key that are compariable
to password-based infrastructure exploits. part of the expiry process
is to bound the life of a specific password exploit (because of its
vulnerability to being learned). a lot of the public key
credentialling infrastructures distract attention by focusing on the
strength of public key operations and/or the credentialling
registration process.  however, a direct equivalent to attackers
acquiring password is attackers acquiring the private key. if you were
looking at the use of expiring as a method of bounding an exploit
... you would compare the probability for an attacker to obtain a
password (via all possible mechanisms) compared to the difficulty that
it might take an attacker to obtain a private key (via all possible
mechanisms). If you determined that it was four times harder for an
attacker to obtain a user's private key ... you might then choose to
make the validity period for a registered public key ... four times
that of a registered password (however, if it was a 20 times harder
for an attacker to obtain a private key ... you might make a public
key validity period 20 times longer). A simple password harvesting
attack might be to obtain the file where the user stores all their
passwords. A possibly equivalent attack on private key is to obtain
the file where the user stores their private key(s)). If the ease of
performing such attack is roughly equivalent and such attack
represents major vulnerability ... then it could be that the
expiration of a password and the expiration of a public key would be

one possible issue in ssh vis-a-vis password ... if major password
exploit is evesdropping the authentication process ... and password
authentication is no longer used (because ssh is using digital
signature) ... then a major factor in needing password expiring for
bounding exploits is eliminated (and the artifact that ssh
registration of public key for authentication hasn't been integrated
into overall system infrastructure of registration business process of
authentication material). however, if the major vulnerability is
acquisition of client stored files containing authentication material
(either password or private key) ... then there could be a need for
more consistent expiring for both passwords and private keys.

Anne & Lynn Wheeler | /

Re: Public key authentication defeats passwd age warning.


Thanks a bunch for getting back to me.  I sure appreciate it.  I was
just about to send basically the same note to openssh-unix-dev, but I
guess I don't have to now...

Quoted text here. Click to load it

Good info, thanks.  Confirms what I'd guessed would be the case.

Quoted text here. Click to load it

Yes, because my customer sez so.  :-)

Seriously, though, the passwd expiration isn't to keep you out,
it's meant to try to help limit the exposure to the unauthorized
folks in case they manage to get your passwd some day.  OK, so YOU
never use the passwd, however, in a sensitive environment, it still
makes sense to me that you'd still want to change it on a regular
basis in the off chance that someone else got their hands on it
and THEY are using it (even if you aren't).  That's what passwd
expiration (in general) is all about, no?

Quoted text here. Click to load it

That part does actually work the ``right'' (depending on your view
of the world) way now.  If I log in and my passwd has expired, but
it's still before my account is disabled due to over-expired passwd,
it prompts me to change my passwd.  Just like if I were logging
in any other way.  If I don't get it changed between the time the
passwd expires and the cutoff, it should then disallow access all
together (haven't tested that part yet, though, but I suspect PAM
is gonna handle that so that should probably work that way, yes?).

That really only covers the login case, however.  I would imagine
that for scp or when you do ``ssh machine command arg'' type thing,
I would think the right behavior should probably be to simply deny
access (yes even with a perfectly valid key), since there's no
guarantee that there will be anyone at the keyboard.  I haven't
tested that either, though.  I spent most of my time trying to
figger out why I wasn't getting my warnings.  Whatever it currently
does is probably fine, though.  That's a topic for another day.

Thanks again for the reply.  I sure do appreciate it.  If you'd
like to narrow down where I should look to try to figger out how
to put those warnings in, I sure would appreciate it.  I'm not at
all familiar with this code.  If I do figger it out, I'll send you
a patch.  If you decide you agree with that behavior, you can stick
it in, if you don't, well, I'll just have my own version, I suppose
(assuming I even *CAN* figger out what to do, of course).

On the other hand, if you know just what to do and wanna send ME a
patch, I'd appreciate that even more!  :-)  I'm sure you could get
it done a LOT sooner than I could (and you'd probably even do it
right, too).


Quoted text here. Click to load it

To reply by mail, remove all lower case letters in my return address

Site Timeline