This is a longstanding bug which I believe is present in all 4.x releases. When connecting to a Tru64 system where sshd was built with --with-osfsia and the user's password is expired, the connect succeeds but the session hangs (until the user disconnects with "~."). This has the effect of locking users completely out of the system unless they always change their passwords before they expire, or there is an alternate access path (such as telnet) to work around the problem. The attached patch corrects this issue for password-based authentication by checking the password status and setting force_pwchange when appropriate. Other authentication methods (including my favorite, public-key-based) are still screwed up because I couldn't figure out where to hook in the password check. :-p I hope this patch, or better yet an improved more comprehensive version, will be included in future releases. Thanks for an indispensible utility, Scott
Created attachment 1194 [details] Add password expiration checking to auth-sia.c
This looks reasonable, however I have no way of testing it. I'm adding it to the list for 4.8 and hoping someone with SIA-enabled Tru64 box can test it. Regarding pubic-key authentication: currently password expiration is only checked for password authentication (although there are some corner cases for, eg, PAM). If the session doesn't work in that case, it would be nicer to provide a nice message and disconnect.
Comment on attachment 1194 [details] Add password expiration checking to auth-sia.c As I said, this looks fine but I can't test it. Can anyone test? I'm leaning toward applying the patch so it can be tested in snaps.
Thank, this has been applied and will be in the 5.1 release.
Mass update RESOLVED->CLOSED after release of openssh-5.1
This patch breaks password-based logins on my Tru64 5.1B systems and should be reverted. The patch should be unnecessary; on my systems, if I attempt to log in (with either password or public key authentication) to an account with an expired password, I am properly prompted to change the password. This is all handled by the SIA session routines.
OK, well we'll roll this back for 5.3 but please figure out amongst yourselves the right way to do this.
I have rolled the change back for 5.3p1. Please figure it what should be changed to make both of your configurations work then let us know.
Mass move of RESOLVED bugs to CLOSED now that 5.3 is out.