When logging into a VM running SLES 11, SecureCRT will immediately output "Keyboard-interactive authentication with the SSH2 server failed", then prompt for a username.
Upon entering the credentials again, the error "Account locked due to 4 failed logins" will print three times, showing 4, 5, and 6 failed logins, respectively.
If I log in as root via console, and unlock the locked account while still connected to the VM via SSH in another SecureCRT window, I'll be able to log in successfully, so I know the password is correct. When I login successfully, I see the following prior to the MOTD (IPs have been redacted; they are all the same IP):
Last login: Wed Jan 18 05:15:48 UTC 2017 from XXX.XXX.XXX.XXX on pts/1 Last failed login: Wed Jan 18 05:31:19 UTC 2017 from XXX.XXX.XXX.XXX on ssh:notty There were 4 failed login attempts since the last successful login. Last login: Wed Jan 18 05:31:31 UTC 2017 from XXX.XXX.XXX.XXX on ssh Last login: Wed Jan 18 05:31:31 2017 from XXX.XXX.XXX.XXX
If I disconnect/reconnect via SSH, and try to log in again, I'll immediately get 4-6 failed login attempts, locking out the account. "Automate logon" is disabled in SecureCRT.
While logged into this account via SSH, the failed login attempts do not increment, so there isn't some other device/service repeatedly attempting to login with the wrong password.
The issue appears to stem from establishing a new SSH connection in SecureCRT; it's almost as if I get multiple failed logins just from connecting, which is why resetting them with pam_tally while the connection is still active circumvents that problem.
Is there any setting in SecureCRT or SLES which could cause this behavior? I don't experience this problem when logging into other VMs running the same SLES version.
I've tried looking this up online, but all I can find is descriptions of how to enable or disable account lockouts due to failed login attempts, or unlock an account which has already been locked.
EDIT: I just got a co-worker to verify that he's seeing an identical issue, and I also confirmed that it also occurs in PuTTY, so it's not a SecureCRT quirk.