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

SSH and Expire Password Dialog with Reflection

Richard W Hunt
Valued Contributor

SSH and Expire Password Dialog with Reflection

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?
Sr. Systems Janitor
13 REPLIES
Brad McCusker
Respected Contributor

Re: SSH and Expire Password Dialog with Reflection

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
Brad McCusker
Software Concepts International
Wim Van den Wyngaert
Honored Contributor

Re: SSH and Expire Password Dialog with Reflection

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)
Wim
Richard W Hunt
Valued Contributor

Re: SSH and Expire Password Dialog with Reflection

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.
Sr. Systems Janitor
EdgarZamora_1
Respected Contributor

Re: SSH and Expire Password Dialog with Reflection

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
Honored Contributor

Re: SSH and Expire Password Dialog with Reflection

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
Respected Contributor

Re: SSH and Expire Password Dialog with Reflection

>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.




Brad McCusker
Software Concepts International
Richard W Hunt
Valued Contributor

Re: SSH and Expire Password Dialog with Reflection

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.
Sr. Systems Janitor
Richard W Hunt
Valued Contributor

Re: SSH and Expire Password Dialog with Reflection

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.
Sr. Systems Janitor
Richard W Hunt
Valued Contributor

Re: SSH and Expire Password Dialog with Reflection

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.
Sr. Systems Janitor
EdgarZamora_1
Respected Contributor

Re: SSH and Expire Password Dialog with Reflection

FWIW, I repeated my test... changing the PWDMIN to 15 (our standard is shorter). It didn't make a difference. I was still prompted to change my password. I tried to change it to a short password and it didn't take. I had to use 15 characters.

Log...

Wed 20 12:50:50 INFORMATIONAL: Starting image in auxiliary server mode.
Wed 20 12:50:50 INFORMATIONAL: connection from "10.10.192.169"
Wed 20 12:50:54 NOTICE: User ezamora's local password accepted.
Wed 20 12:50:54 NOTICE: Password authentication for user ezamora accepted.
Wed 20 12:51:09 NOTICE: User ezamora's local password not changed, Password too short; please choose a new password..
Wed 20 12:51:32 NOTICE: User ezamora's local password changed.
Wed 20 12:51:32 NOTICE: Password changed for user ezamora.
Wed 20 12:51:32 NOTICE: User ezamora, coming from bon-f1jncg1.sourceinterlink.com, authenticated.
Wed 20 12:51:37 INFORMATIONAL: Local disconnected: Connection closed.
Wed 20 12:51:37 INFORMATIONAL: connection lost: 'Connection closed.'
Richard W Hunt
Valued Contributor

Re: SSH and Expire Password Dialog with Reflection

Further informational update:

I note that the usual informational notices don't come up right, either. Like, "You have {a gazillion} new mail messages" and "Last successful login {some date}" either. Even though the account is enabled for same. Is there an SSH parameter that governs this stuff that normally occurs before executing SYLOGIN but after the password challenge?

I also note that the actual SSH session is a local session that is a child of a parent session running TCPIP$SSH. Would being a child session have anything to do with the problem?

I also note that the TCPIP$SSH_RUN.COM file seems to accept parameters. It takes -i and -d for certain. The -i parameter does not have an argument so it isn't quite the same as the SSH command's -i parameter.

Is there some other parameter I need to set on this command line? I've already had to edit that -RUN.COM file to make it stop purging logs because my restricted users were getting kicked out early in the session because the -RUN script was trying to purge log files open by other users.

I found and downloaded and read the OpenSSH Users Guide for OpenVMS .PDF for my version. I have read that inbound SSH will not go through the password change dialog for the non-OpenVMS login case. Which now confuses me because sometimes it actually DOES go through this dialog. Sometimes.

I'm about ready to do a workaround of some sort just to see what is visible to the user and maybe put a hook in the SYLOGIN file to check for the specific case of SSH login with an expired password. If I can see that level of detail.

It isn't a great solution but at least if I can tell the users SOMETHING before their accounts go >>>pbbbttt<<< at them, maybe they won't try to ignite the tar and feathers when they run me out of town on a rail.
Sr. Systems Janitor
Ian Miller.
Honored Contributor

Re: SSH and Expire Password Dialog with Reflection

I wonder if this another consequence of SSH not using the standard routines for login processing :-(

Fixing SSH to use the standard stuff would fix several issues I think.
____________________
Purely Personal Opinion
Richard W Hunt
Valued Contributor

Re: SSH and Expire Password Dialog with Reflection

Didn't realize that SSH didn't use standard login stuff. Does that mean that it "rolls its own" security setup and the like? Does it fill in the ORB and other security structures or is that a CREPRC call?

In any case, I'm now testing whether it is possible for my SSH interactive users to test their own SYSUAF information in enough detail to decide that their passwords are expired. There is also the GETJPI stuff that definitely shows me the UAF_FLAGS parameter, should be easy to decide if PWD_EXPIRED is set there. I have a utility that tries to make calls to the SYS$GETUAI service entry point, but don't know exactly how this will work for a user trying to read his/her own record.
Sr. Systems Janitor