Apologies that this is a bit long, but I didn't want to leave out config info that might help someone figure out what's up.
Site runs 2 x OpenVMS/Alpha 7.3-2, patched as recently as possible. TCPIP Services for OpenVMS/Alpha 5.4 ECO 7. SSH "-V" gets back "SSH Secure Shell OpenVMS (V5.5) 3.2.0 and AlphaServer ES40 - VMS V7.3-2"
One server is a production system, the other is the test/development box for the production system. Identically configured except for the specific disks they talk to. Separate system disks, but one is a copy of the other, different only in the network specifics like interface names and numbers, domain names, etc. The SSHD2_CONFIG files are an exact copy of one another except for server key names (KEY_22_NODE_DOMAIN_ etc etc etc).
Both machines are configured via password policy module to require complex passwords with upper case, lower case, punctuation, and digits. Users are required to have passwords not less than 9 characters; some are set higher due to privileges on their account. This is a DoD machine so I'm required to make it that complex. These features were tested before and after enabling SSH. No problems noted at any time. The policy module ONLY looks at the clear-text password and says OK or BAD.
Our environment has SOME user accounts that log in batch-mode, server to server, using RSA 1024 or higher keys. No problems there.
The problem user is in the group that uses interactive sessions. They are allowed to log in via password exchange but must have the server's key on their client desktop machine. The ones who use passwords cannot use RSA keys because of DoD regulations about the keys they are required to use from workstations.
The servers in question are running as SSH servers to a series of Windows clients running Reflections v 14.0 or later. We are configured to use protocol 2 only, all the ciphers and hashes are allowed EXCEPT "none." The "Re-use existing session if possible" is UNCHECKED. (Doesn't work right if you check it.)
We have two NICs on the box, one to a purely in-house network not exposed to the outside world, on which TELNET is still allowed. Very short-run network, and our users are nation-wide if not world-wide, so putting them on the TELNET-only network is not an option. We have an interface exposed to the world on which ONLY SSH-style login is allowed.
OK, enough configuration and architecture:
I have a user who has problems logging in to the test/dev box but not the production box. I have been able to sporadically duplicate the conditions but so far haven't found out why, and there is no regularity to it. Sometimes it happens, sometimes not.
She clicks the pre-defined Reflections icon that includes the host name and her username, gets the "enter password for username" challenge OK, and enters her password. She claims to have a 20-character password on the production box, which likes what she does and lets her in. The same password on the test/dev box does not let her in.
So I thought, maybe the passwords somehow got desynchronized. After warning the other developers, I copied the production SYSUAF file to the test/dev box - but my problem user is still unable to log in. Keeps getting a request for the account's password - which is typical behavior for failing login.
Eventually it tosses her off when it reaches three failed attempts. She shows up in the intrustion list. I reset that list. She tries again. Fails again.
If I then manually change the password on the test/dev account to something that she has to change at next login, she can get in on the next attempt AND the change works fine. All this time, she still has no problem on the production box. The date of last password change on either account is less than a week old at the time this happens, and her password lifetime is 60 days, so it was not an expired password. Her login flags don't have DisUser set, so that's not it.
Other symptoms & comments: I have a 15-character password on both systems. Using the in-house sub-net that allows TELNET, I can get in OK. Using the other network and the same exact password, it locked up on me this morning via SSH. Once it locks up, I can't get in on that subnet - but still can log in with the same password on the TELNET-allowed subnet.
I check for intruder records and sure enough, I'm listed as an intruder. From the TELNET session I delete the intruder records, wait a couple of seconds, and try again. Still locked up.
Later on in the day, both networks let me in via SSH on the same password, no hesitations. This smells to high heaven like there's a hidden timing issue that I'm not controlling and not aware of. But the manual that came with the SSH download doesn't seem to address this kind of timing issue.
Anyone out there have any ideas?
Sr. Systems Janitor
