Chris,

Is there anything useful at all in the /var/log/{secure,messages} logs (performing a tail -f /var/log/{messages,secure} on the system being scanned while from the scanning system it is attempted? Maybe rotate the logs prior with logrotate -v -f /etc/logrotate.conf and logrotate -v -f /etc/logrotate.d/syslog just so you have fresh logs to view.

Any chance the system performing the scan is on a new subnet that is not within /etc/hosts.allow??? But since the account is locked...

Did anyone (to borrow Tom Jones' questions from another thread) dork up SELinux labels or ssh-related users/groups, or perhaps any changes to iptables/ip6tables? (The latter might be possible, the former less likely since you can ssh to it otherwise.)

What happens (if the system attempting the scan is Linux) an authorized user runs ssh -q knowngooduser@targetsystem 'hostname' is ran from the system doing the vulnerability scanning?

The thing that seems (at least to me) point to the system performing the scanning is the fact you can log in (I assume maybe) elsewhere with the proper userid/password. I have one customer that has a vulnerability scanner that they can install on a system, and save the password (can not be viewed after save), and they entered it wrong, even though they copied/pasted, they had an extra character they weren't banking on. However this doesn't seem to be your case...

How is the authentication (if you can say here or not), is it using local accounts, NIS, an exotic version of 3rd party LDAP (rhel5 was rather challenging to get LDAP to work without 3rd party solutions).

We had some RHEL 5 systems at one time that when the domain controller would run out of space for its system logs, it would fail for authentication. The 3rd party LDAP solution we had was tied to one specific domain controller. If that DC was not available for whatever reason, authentications would fail. However since you can seem to log in otherwise, this doesn't seem likely.

Some questions... 1) is the system performing the scan Linux or another OS? 2) If it is Linux, is there any chance there are host keys on that vulnerability scanner that needs to be accepted for that user since the host keys changed? 3) Is there any chance the permissions on the .ssh directory or subordinate files in that directory changed if ssh keys are involved? However it seems you're using a userid/password, and not ssh keys.

Is there anything in the /etc/bashrc file or /etc/profile that would cause an abnormal exit (on the system being ssh'd to)? Or did someone add some echo statement? I can't immediately remember, but one time (many years ago) I accidentally polluted either the /etc/bashrc or /etc/profile (can't remember which) with some echo statement with a reminder, but it thwarted logins, and I removed it and logins were restored... less likely since you can ssh to it otherwise.

Hope this gets sorted out. Perhaps if you can, run an strace command prior to the ssh action, if that is even feasible and shunt the output to a file for analysis. Some do tcpdumps and analyze with wireshark if appropriate.

Wish you well with this Chris,

-RJ