Red Hat Bugzilla – Bug 99357
Password changing hangs with multiple simultaneous users connect via SSH
Last modified: 2007-03-27 00:07:54 EDT
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:
Always (twice in this case)
Steps to Reproduce:
1. Add a lot of new users (40+), whose passwords are set to expire upon initial
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
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).
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
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.
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.
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.
Probably a duplicate of bug 75454
*** This bug has been marked as a duplicate of 75454 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.