Two SPARC servers running latest patches on S10U11. When the mysql account logs into either machine from a windows 7 workstation via putty or other ssh program, the first attempt works fine. Trying to ssh in from the same terminal a second time using either the mysql account or any other LDAP account yields an immediate Connection Refused response. This refusal will continue for several minutes. Logging off the first mysql session does not allow another login from any account until whatever is happening times out. Logging into multiple sessions with other accounts from the same workstation works fine; this appears to be tied to the mysql account.
While attempted logins are getting the Connection Refused message while trying to connect from the windows workstation, sshing to the machines from any other Solaris/Linux box (even using the mysql account) works fine.
Well, here's the interesting thing. I use putty and turn on logging and the log is empty. So I use the SSH that comes with Cygwin and -vvv tells me that it checks the stuff in ~/.ssh, enables compatibility mode for protocol 2.0 and then "ssh_exchange_identification: Connection closed by remote host." Period. End of communication.
This is another explanation. SSH to Solaris 10 (u11) box as LDAP user mysql from windows workstation. Login successful. Try to log in to the same Solaris box as any other user. Fails with unexpected disconnect mesage. In the meantime, you CAN ssh into the box from another Solaris 10 machine as any account, including mysql. This only seems to happen when you log in as mysql.
It is as if the Solaris machine allows mysql to have only one session per ip per x number of minutes.
---------- Post updated at 11:57 AM ---------- Previous update was at 08:52 AM ----------
Another update. When "mysql" user logs in, an entry is made automatically in /etc/hosts.deny: ALL:ip.add.rr.ess where ip.add.rr.ess is the my workstation ip.
I do not know what is causing this entry; it does not do it for any other account. TCP_wrappers does not appear to be running; I don't see anything in cron to indicate there is some other script running that could be checking the ssh logs, etc. Removing hosts.deny from /etc seems to alleviate the issue for now.
There's nothing in root's (or anyone else's) crontabs that would do this.
Only root has write access to hosts.deny. The OSSEC group has read access.
Before lunch, I renamed hosts.deny to hosts.deny.org. When I came back from lunch, it recreated hosts.deny. Sure enough, I logged in as mysql and the ip deny line is added into hosts.deny.
Some people read Ellery Queen or Sir Arthur Conan Doyle. They should just follow me around because I'm always finding stuff like this.