Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

SSH (daemon) and Expired Passwords

Richard W Hunt
Valued Contributor

SSH (daemon) and Expired Passwords

Sorry for what is going to be a long post, but I did a LOT of digging before I resorted to posting here.

We are running: OpenVMS 7.3-2, TCP/IP Services for OpenVMS 5.4 ECO 7, and our users are running Windows (various but mostly XP) with Reflection 14.0.various. We have lots of "field" users (out in the enterprise-wide intranet) that fall into the Non-OpenVMS login category, never otherwise.

In the past, I posted questions about the problem of expired passwords. The forum consensus was that my version of SSH was a little "touchy." Finally I had to take matters into my own hands because SSH was not doing the right thing no matter what I tried parameter-wise.

I have a utility that lets me export a raft of DCL local symbols containing miscellaneous SYSUAF information such as login flags, last login dates, ... just a bunch of stuff. Most of the time this won't work without privilege, but it uses SYS$GETUAI and there is a loophole in that system service. You are always allowed to look up your own parameters even if non-privileged. Therefore, anyone could use it to look up their own account information. And scripts can use the DCL symbols that get returned via LIB$SET_SYMBOL. I modified our site SYLOGIN.COM and added a little set of checks that said, in essence,

1. if you are interactive and
2. this is a LOCAL login (which is how SSH is reported), and
3. Your terminal type is FTxx: and
4. your login flags say your password IS expired now and
5. your date of last password change is at least PWDLIFETIME old then

6. Force you to change your password and don't let go of you until you do so.

This works fine for those users who get to that point in the script. But here is where things get crazier.

I think sometimes Windows Reflection and SSH still try to do the Windows-style password reset through SSH facilities, i.e. SSH asks Reflections to ask the user for a new password, which it attempts with a Windows-style dialog box. The dialog for my forced password change is interactive such as you would see from using the SET PASSWORD command. Therefore, the user can tell the difference of which one occurred if you know the question to ask.

Some of my users are still seeing the Windows dialog that Reflection tries to trigger. Others are NOT seeing it, but SSH thinks it asked anyway. Then it locks the account and denies the login. (Says "wrong password.")

Here are some excerpts from the log files for a single user who has this problem, with username and IP addresses obscured (only for this posting) because of my site security requirements:

From Wed 15 Jul 2009 07:45:22 -

NOTICE: kbd-int: passwd: user xxxxxx's local password accepted.
INFORMATIONAL: kbd-int: passwd: user 'xxxxxx' forced to change password.
NOTICE: User xxxxxx, coming from 10.y.y.y, authenticated.

That seems to be a case where the Windows dialog was used and actually worked. EXCEPT that the audit logs don't show that the password was updated. The next dialog is for the same user a few minutes later as he decided to test his new password.

From 15 Jul 2009 07:53:14

WARNING: kbd-int: passwd: wrong password given for user 'xxxxxx'.
ERROR: auth-kbd-int: client sent us fewer responses than we sent requests (sent: 1, recv: 10).
WARNING: Protocol error in keyboard-interactive when parsing received response packet.
WARNING: Wrong password given for user 'xxxxxx'.

The user claims that he used the correct password by entering in "hunt and peck" mode rather than touch-typing. I have enough other examples that I tend to believe him. I can't reproduce the problem for my own account and that is somewhat frustrating, too. When I look at the SEC_JNL files (audit logs), it SEEMS that the password update doesn't always "take" if SSH and Windows conspire to do the update. That is, I can see times when the user sets his/her own password. But they don't always correspond to the TCPIP logs.

So part of the problem is that SSH and Reflections don't communicate as well as we would like, certainly not consistently. As a short-term workaround until we update to OpenVMS 8.3 and TCPIP Services 5.6, I an contemplating a change to SSHD2_CONFIG to block SSH from forcing the change.

OK, finally, here is the REAL question, after all that setup:

If I take "keyboard-interactive" out of the list of AllowedAuthentications, that should disallow the attempt to reset the password via SSH mechanisms (I think). The user would still be allowed to login due to parameter AllowNonvmsLoginWithExpiredPw (=YES). At that point, my SYLOGIN whiz-bang would kick in, stop the user, and force the login change.

Do I need "keyboard-interactive" as an allowed authentication if I also have "password" allowed? Is there any other system function that requires "keyboard-interactive" to be allowed for "AllowedAuthentications" if I take care of password changes in the way I described?

Sr. Systems Janitor
Peter Zeiszler
Trusted Contributor

Re: SSH (daemon) and Expired Passwords

Isn't keyboard interaction also used if anyone uses any other SSH functions and types in the password? Like from a system that hasn't been communicted with before.
Richard W Hunt
Valued Contributor

Re: SSH (daemon) and Expired Passwords

Peter, thanks but I don't think that is the case. For a system that doesn't know my server, the CLIENT downloads the server public key, which is not a keyboard-interactive action (I think) and then locally asks whether to trust the public key. I don't think that dialog is keyboard-interactive. Besides that, it is a client-side message using the client's equivalent of the ssh2_config. file.

The parameter I was describing is the server-side or sshd2_config. file's contribution to this problem.

What I'm seeing is that my example user gets the password change dialog and logs in correctly. But there is no entry that shows where the SYSUAF entry was updated (with the new date of password change). The password ends up not being updated, either. However,the SSH logs indicate that a dialog DID occur and the password WAS updated. This confuses the crud out of me because normally I would expect the two log files to at least tell me a consistent picture of what is going on.
Sr. Systems Janitor