SSH and Expire Password Dialog with Reflection

[EdgarZamora_1]

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]

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.

[Ian Miller.]

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.

[Richard W Hunt]

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.