|Summary:||Password changing hangs with multiple simultaneous users connect via SSH|
|Product:||[Retired] Red Hat Linux||Reporter:||Need Real Name <shanew>|
|Component:||pam||Assignee:||Tomas Mraz <t8m>|
|Status:||CLOSED DUPLICATE||QA Contact:||Mike McLean <mikem>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-21 18:57:06 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Need Real Name 2003-07-17 23:45:33 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Description of problem: I'm not sure passwd is even the right component to report this under, because it's not clear to me at which stage things are hanging. If we create a slew of new accounts (40+) with assigned passwords that will expire on initial login and then have users connect to the server via Secure Shell (Commercial Windows client), there is a tendency for most of these connections to hang after initial password validation. In other words, say 20 or 30 users connect at the same time to login and change their passwords, each user can successfully authenticate but the vast majority are never shown the "your password has expired" prompt. System load during this doesn't appear to increase significantly (load remained under 1 on a dual processor system). Closing their SSH client and reconnecting doesn't seem to solve the problem either. We have witnessed this behavior twice since upgrading to RH 7.3 from RH 6.2 and changing from the Commercial SSH server to openssh. Current rpms for all the components that I can think of that might be involved are: passwd-0.67-1 openssh-server-3.1p1-6 pam-0.75-46.7.3 cracklib-2.7-15 getty_ps-2.0.7j-9 How reproducible: Always (twice in this case) Steps to Reproduce: 1. Add a lot of new users (40+), whose passwords are set to expire upon initial login. 2. Have them login from Windows using the commercial SSH client (v2.3 I think) and enter their usernames and passwords. Actual Results: One or two of the users get prompts to change their password (and can do so successfully), but most get hung before the prompt even appears. We've waited a few minutes to see if any of the hung sessions go through (which they don't), but this is in a live classroom setting, so we've had to improvise pretty quickly. Expected Results: All sessions would prompt and allow the users to change their passwords (as they could do under RH 6.2 with the Commercial SSH server). Additional info: I could find no errors in system logs, nor did the users ever see error warnings on their side of the connection. I thinked I've turned on more debugging in the pam modules, so a repeat performance might yield more info, but I'm not sure pam is where the problem is even occuring. Also, during this hang, users with non-expired passwords appear to be able to log into the system just fine, but we haven't tested this extensively.
Comment 1 Need Real Name 2003-08-19 17:55:32 UTC
I've had a chance to further experiment with this and have some info that helps narrow things down some. I now suspect the problem lies in pam somewhere and have changed the component field accordingly. First, during our recent test, I also launched the commercial version of secure shell on a different port, and it exhibits the same lock-up behavior as when connecting to openssh, so I guess it's not in openssh. Second, in a controlled environment we could tell that the first "expired" account to log in gets the note that they need to change their password, and then gets the password changing prompt. All other "expired" accounts after that hang after the note and don't show the password changing prompt. Once the first account changes the password, one of the others will get a prompt, but the rest stay hung. Change that one, and it happens like that again. Third, we were able to confirm that users with non-expired passwords could continue to log in and out normally during this hang, so it doesn't appear to passwd after all.
Comment 2 Need Real Name 2003-08-25 16:52:16 UTC
When I submitted this nearly three months ago, the priority was normal, but now I'm moving it to high, since we expect to have large groups of users logging in for the first time as the semester starts.
Comment 4 Tomas Mraz 2004-09-16 12:32:35 UTC
*** This bug has been marked as a duplicate of 75454 ***
Comment 5 Red Hat Bugzilla 2006-02-21 18:57:06 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.