Bug 98330 - openssh server can not handle expired accounts.
openssh server can not handle expired accounts.
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: openssh (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
: Security
Depends On: 83585
Blocks: CambridgeTarget
  Show dependency treegraph
Reported: 2003-07-01 05:01 EDT by Nick (Gunnar) Bluth
Modified: 2007-11-30 17:06 EST (History)
4 users (show)

See Also:
Fixed In Version: openssh-3.6.1p2-33.30.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-31 06:46:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to enable pasword expiration/updating with Privilege Separation turned off (840 bytes, patch)
2003-09-16 15:00 EDT, Neil Horman
no flags Details | Diff

  None (edit)
Description Nick (Gunnar) Bluth 2003-07-01 05:01:38 EDT
Description of problem: 
Connections of users w/ expired accounts are closed at once. 
/var/log/secure shows: 
PAM rejected by account configuration[12]: Authentication token is no longer valid; 
ew one required. 
Version-Release number of selected component (if applicable): 
How reproducible: 
Steps to Reproduce: 
1. chage -d 2003-03-01 -M 80 <user> 
2. ssh <user>@<host> 
Actual results: 
User is kicked out 
Expected results: 
User is prompted for new password 
Additional info: 
This is documented as a known problem: 
Comment 1 Eric Hopper 2003-08-07 11:07:00 EDT
I've had this exact same problem, and it's highly annoying for my users, some of
whom only log in once every few months.
Comment 2 Neil Horman 2003-09-16 15:00:33 EDT
Created attachment 94530 [details]
patch to enable pasword expiration/updating with Privilege Separation turned off

This patch allows password expiration/updates to work properly as long as
UsePrivilegeSeparation is set to no is /etc/ssh/sshd_config.  For some reason
the code which handles password changes was #if0-ed out in sshd, but it appears
to have no effect on system operation is separation is turned on.
Comment 3 Giuseppe Raimondi 2003-11-21 09:33:04 EST
This seems to affect Red Hat Enterprise Linux 3 too. Any chance to see
a fix (at least for RHEL)?
Comment 4 Nick (Gunnar) Bluth 2003-12-12 07:09:39 EST
Any news regarding this? 
At least a user "&npsb; &nbsp;" has closed our service request.... 
We're really suffering from this, since you have to ask a colleauge 
to reset your password if it expires (which is no fun at, say, 3 a.m. 
on a Sunday....) 
Nick (Gunnar) Bluth 
Comment 5 Giuseppe Raimondi 2004-01-09 10:17:18 EST
Any chances to see a fix soon?
Comment 6 Nick (Gunnar) Bluth 2004-02-24 12:15:07 EST
It's ridiculous! 
Our service request (open since Nov. has been closed _again_, but 
this time, I can't reopen it (!). 
This request is from Nov 20., 2003, there are patches to fix the 
problem, and it affects the EL 3 line. 
With this "feature", RHEL is not really "enterprise ready", so why 
don't we see any motion in this?!? 
It would be nice to at least see this bug changing from "NEW" to 
something more motivating (e.g. "ERRATA" ;-)..... 
Giuseppe, I hope "contract" is a higher priority...?  
We really do suffer from this! 
Nick (Gunnar) Bluth 
Dresdner Kleinwort Wassestein 
Dresdner Bank AG 
Allianz Group 
Comment 12 Eric Sammons 2004-04-09 10:50:07 EDT
I have not seen this problem in SuSE EL 8, perhaps SuSE is ready for
the enterprise and Redhat is not?  I am currently having this problem
in my environment with my RHEL 3 systems and it is rather
unacceptable.  We are an ssh only shop that sets  passwords and then
likes to use the force on next login option.  (good security measure,
but can't be implemented as long as this problem exists.)
Comment 13 Nick (Gunnar) Bluth 2004-04-13 12:15:39 EDT
As I see, this is still "NEW", 'though #83585 says there is a fix "in 
sight"... that was 2004-03-04, also more than a month ago... 
Looking at the first entry shows: 
Opened by Nick (Gunnar) Bluth (bluth@muenster.de) on  
2003-07-01 05:01  
I mean, this is no longer funny, is it? 
We had to manually un-age 12 developers on 24 boxes. This probably 
took us more time than applying the patch and releasing an Erratum 
would have taken at RH.... 
Comment 14 Alexandre Oliva 2004-07-31 06:46:53 EDT

Note You need to log in before you can comment on or make changes to this bug.