Bug 98330 - openssh server can not handle expired accounts.
Summary: openssh server can not handle expired accounts.
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: openssh   
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
Keywords: Security
Depends On: 83585
Blocks: CambridgeTarget
TreeView+ depends on / blocked
Reported: 2003-07-01 09:01 UTC by Nick (Gunnar) Bluth
Modified: 2007-11-30 22:06 UTC (History)
4 users (show)

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 10:46:53 UTC
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 19:00 UTC, Neil Horman
no flags Details | Diff

Description Nick (Gunnar) Bluth 2003-07-01 09:01:38 UTC
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 15:07:00 UTC
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 19:00:33 UTC
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 14:33:04 UTC
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 12:09:39 UTC
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 15:17:18 UTC
Any chances to see a fix soon?

Comment 6 Nick (Gunnar) Bluth 2004-02-24 17:15:07 UTC
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 14:50:07 UTC
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 16:15:39 UTC
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 10:46:53 UTC

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