SSH and Expire Password Dialog with Reflection

[Richard W Hunt]

Before we start, I have searched the forum for this topic. No joy in the searches so far, though I have seem some things that I tried before posting.

System: OpenVMS 7.3-2, TCPIP Services for OpenVMS 5.4 ECO 7. SSH is enabled and started. No special network filters in place for allowing or denying hosts.

Client: Reflections 14 + change, running on varying versions of Windows workstation (NOT a server edition) from 2k3 to XP.

SSHD2_CONFIG. file contains, among other parameters, these settings:

SysLogFacility AUTH

AllowedAuthentications publickey, keyboard-interactive, password

AuthKbdInt.NumOptional 1

AuthKbdInt.Optional password

AuthKbdInt.Retries 3

Password Guesses 3

AllowHosts localhost, *

AllowVMSLoginWithExpiredPw yes

AllowNonvmsLoginWithExpiredPw yes

UserLoginLimit 50

In the applicable Reflections SSH client config file, the relevant settings are

Protocol 2

PreferredAuthentications publickey,keyboard-interactive,password

matchhostname no

Relevant user login flags:

DISFORCE_PWD_CHANGE is FALSE, PWDMINIMUM is 14, we are using a VMS$PASSWORD_POLICY module which seems to work for the SET PASS command and we have PWDMIX set.

OK, problem statement:

User's password expires. So user logs in because the AllowNonVMSLogin... parameter is set to YES. But the user does not reliably get prompted for a new password and gets no warning at the screen. I am able to diddle around with the various password settings including using the /PWDEXPIRED option (that pre-expires the password) and clearing the login flag that separately says PWD_EXPIRED.

I've managed to make the login go through the "change password" dialog on the Windows Client ONCE. I cannot reproduce what I did because doing the same exact thing a second time didn't trigger the dialog box. When that box comes up, it works ok. But I cannot make it come up reliably.

When I look at the TCPIP$SSH_RUN logs, the same informational message is present for each of the tests:

INFORMATIONAL: kbd-int: passwd: user '{username}' forced to change password.

The catch is, I see that in the log for the session that actually changed the password and for sessions where the question was not asked. The log for the session that actually ran the dialog box showed more detail lines.

In some SSH RUN logs, I do see a message that says "Packet integrity error" - but only AFTER the message that says "User {username}, coming from {ip addr}, authenticated." That very well could have been me doing something I shouldn't have done with the session to close it. Like, click the disconnect button. So I discount that particular error.

I found a couple of threads in the forum that mention the SSHD2 parameger UserLoginLimit, for which there is some lengthy discussion. The suggestions that were made included making this non-zero. In my case, I tried this on the test system by stopping SSH, editing the SSHD2_CONFIG file, and re-starting SSH. The comments say UserLoginLimit of 0 means "no limit." The threads say this is sometimes not correct. I can tell you that it doesn't work when the value is 0 or when it is 50. Same erratic/incorrect behavior.

In essence, I have what appears to be inconsistent behavior for users who should, but do not, get the "Please reset your password" dialog box. Yet when I see that box, it works correctly if you give it the right old password and verify the new password correctly. I need it to be a bit better than "inconsistent" and "sporadically works like it should."

Any suggestions?

[Brad McCusker]

Richard,

Your setup and config match what we do. The only differences are the we use TCPIP V5.6 and we do NOT use Reflections. We use Kermit.

I do notice that the V5.6 Release Notes (http://h71000.www7.hp.com/doc/83final/tcprn/tcpip_v56_rel_notes.pdf) include discussion of a fix for "SSH Server Does Not Allow Password Change " - I have no idea if that is your problem or not, or even related. Might be something to check out.

Along the lines of narrowing down the problem - did you say it worked exactly one time, and then subsequently did not work? Did you try to reboot the client and see if it works again, exactly once? (I know - doesn't solve the problem, but, might help further quantify it)

Have you tried any other clients? It might be worth firing up Kermit or Putty to validate if it's the server or client that is having the problem.

Brad McCusker
Software Concepts International
www.sciinc.com

[Wim Van den Wyngaert]

The client user is not forced to change the password before logging in when:

The connection is from a different SSH implementation to an OpenVMS system and the AllowNonvmsLoginWithExpiredPw parameter is set to yes in the client configuration file. In these cases, the pwd_expired flag is set in the user's SYSUAF record, so that any future attempts to log in will fail if the password is not changed during the current session.

Wim : wasn't pwd_expired when the login started ? Thus all new logins will succeed too ?

Wim (lucky, here expiration is managed by the user himself)

[Richard W Hunt]

To Brad: Your link to that .PDF doesn't resolve, or at least I can't get to it on my military network.

To Wim: What you say doesn't quite sound right somehow. I wonder if I misunderstood the AllowNonvmsLogin... flag's meaning. Are you saying this should be set to NO? I'll try that and defer assigning points until then.

To both responders (and any others): Yes, I mean that I got it to work as expected once and once only. Out of maybe a dozen tries.

The sequence starts with me resetting the password on an account I use for testing. I explicitly do not use the /NOPWDEXPIRED option when I modify the password, so that means the password change date gets set to something impossible. Like, was it 0 or -1 that it gets set to? Don't remember the internals that well, but it is one or the other. To my way of thinking, that would trigger a forced password change - because we do not set the DISFORCE_PWD_CHANGE flag. Dept. of Defense says we MUST force password changes. (And therein lies the reason for this becoming a problem.)

So I go to log in - and get in without a "change password" dialog or challenge. From another session running with higher privileges, I check the SYSUAF entry and sure enough, the FLAG named PWD_EXPIRED is now set when it wasn't before. If I log out now and try to log in again, it is disallowed. Shows up as an intruder record eventually, so I have to clear that, too.

Reset via /FLAG=NOPWD_EXPIRED, and at the same time use the /PWDEXPIRED option. I know most of you know this, but to demonstrate that I know what it means, this should clear the particular login flag and set the date of last password change so that it shows up as "(pre-expired)". Repeat the experiment. No joy.

Move to our other test machine on which I could do this without disruption. Same behavior, no joy.

Adjusted the SSHD2_CONFIG. parameter UserLoginLimit from 0 to 50. Stop and restart SSH on that box. I also have TELNET access, so it isn't that hard to manage. But the users in the field do NOT have TELNET access, they are forced to use SSH. Which is why I'm pounding on this problem. Back to the problem: No joy, same behavior, no "change password" dialog box. The UserLoginLimit does not seem to control the issue.

Yet one time - and ONLY one time - yesterday, when I was doing the testing, I got a pretty little window with dialog boxes for old password, new password, and the verification. Just like you might expect. So I know it CAN work. I just don't know why it chooses to work when it does.

[EdgarZamora_1]

This works for me correctly on OpenVMS ALPHA 8.3 latest patches and HP TCPIP Svcs. It's worked for years now (even with 7.3-2). Reflections version 11 and later in use.

My relevant SSHD2 config commands are:

AllowVmsLoginWithExpiredPw yes
AllowNonvmsLoginWithExpiredPw yes

I just ran a test. I set my pwdlifetime to 1 minute then tried to login using Reflections. It prompted me to change my password. The log file is as follows:

Wed 20 07:37:29 INFORMATIONAL: Starting image in auxiliary server mode.
Wed 20 07:37:29 INFORMATIONAL: connection from "10.10.192.169"
Wed 20 07:37:46 NOTICE: User ezamora's local password accepted.
Wed 20 07:37:46 NOTICE: Password authentication for user ezamora accepted.
Wed 20 07:38:10 NOTICE: User ezamora's local password changed.
Wed 20 07:38:10 NOTICE: Password changed for user ezamora.
Wed 20 07:38:10 NOTICE: User ezamora, coming from bon-f1jncg1.sourceinterlink.com, authenticated.
Wed 20 07:38:19 INFORMATIONAL: Local disconnected: Connection closed.
Wed 20 07:38:19 INFORMATIONAL: connection lost: 'Connection closed.'
TCPIP$SSH job terminated at 20-MAY-2009 07:38:19.86

[Hoff]

FWIW....

Richard, the link to the release notes does resolve (from here), though it appears possible you've encountered one of the various and sundry ITRC bugs.

Check the syntax of the URL, and try again. The following should work around the ITRC bug:

http://h71000.www7.hp.com/doc/83final/tcprn/tcpip_v56_rel_notes.pdf

Note that ITRC software (also) does not honor the classic URL embedding notation, and the following RFC-compliant (rfc1738) notation will fail:

<>

[Brad McCusker]

>To Brad: Your link to that .PDF doesn't
>resolve, or at least I can't get to it on
>my military network.

Go to hp.com/go/openvms and drill down into the documentation set, tcpip services and look for the V5.6 release notes.

But, I think Edgar already said he had it working on the older version of TCPIP and further, I'm not sure the section I quote is relevant.


>I wonder if I misunderstood the
>AllowNonvmsLogin... flag's meaning. Are you
>saying this should be set to NO?

AllowNonVMSLogin should be set to YES

>Client: Reflections 14 + change

I assume this is the latest version of Reflection? Sorry to ask, but, I really suspect this problem is on the client side.

[Richard W Hunt]

Got an update on this one, and it is bizarro!

One key parameter is... /PWDMINIMUM=14

The user in question had 15. Windows apps tend to assume that the Windows password standards apply (when they shouldn't), which makes this ALSO a client-side problem. For you Reflections users out there who are having trouble with the "Reset password" dialog, take heed.

Now, here is the trick: This morning it reliably asks the question but eventually goes bonkers and goes away if you give it a 15-character password for the new password and verification. The password reset "takes" if you shorten that to 14 as a minimum size. But it still "feels" wrong. I'll continue to test to see if this is a "works today, doesn't work tomorrow" case. Therefore, not quite ready to close this puppy.

[Richard W Hunt]

Supplement: In my original problem description, I said the user had PWDMIN of 14 and then in my update, talked about 15. On one system, it was 15. I had diddled with a few settings on another system, that was one of them. So it looks inconsistent, but yesterday PWDMIN didn't seem to make a difference. Today, it does - and yet I didn't change anything except to experiment with SSHD2_CONFIG's AllowNonvmsLogin... setting it to NO and then back to YES. Setting it to NO blocked any login at all. So it has to be YES. But that's ALL that I did at the system level. All other changes were at the user account level or on the client side to clear the flag about host name matching key name.

[Richard W Hunt]

FWIW - we have an upgrade project on the books to bring our s/w up to OpenVMS 8.3 and that would enable us to use TCPIP 5.6, but we were waiting for a third-party vendor to upgrade HIS stuff before we could get there from here. Typical way of the world, right?

Anyway, thanks for the comments Edgar. I suspect I'll just close this can of worms and open another one when I get to OpenVMS 8.3/TCPIP 5.6 - so again, what else is new? Yet I'm glad to know that it worked OK at your 8.3 site. It helps to be able to tell my managers that I have feedback on the issue.

As to age of Reflection? Recent enough to be Attachmate and not WRQ, but maybe not the very latest/greatest version. The down side of working on a government site is that you aren't always allowed to upgrade everything right away. Goverment managers ALWAYS want to put their stink on your project, so there is ALWAYS some paperwork to file and the "chop chain" is invariably longer than anyone wants to face.

Sometimes, our delay isn't because of technical reasons but because someone at a much higher Navy Echelon wants to know what we are doing. Despite the fact that they can barely SPELL OpenVMS, much less know what it is. Some folks aren't so sure it is just a joke, but the current joke around here is that you can't even leave the bathroom without finishing the paperwork first.