These are not errors. They are reports on incoming SSH connections.
Looks like there are three different connection attempts:
Jun 14 16:01:02 sd1 sshd[1062]: Did not receive identification string from 200.80.1.20
Here, sshd child process with PID 1062 reports a connection attempt that did not properly send an identification string, as the SSH protocol would require.
(This might be someone telnetting to the SSH port, or a monitoring system making a connection to the SSH port to make sure sshd is still running on this host.)
Jun 14 16:01:02 sd1 sshd[1063]: SSH: Server;Ltype: Version;Remote: 200.80.1.20-50169;Protocol: 2.0;Client: 3SP_J2SSH_Hewlett_Packard_Company
Here a different sshd child process (PID 1063) reports a connection attempt from host 200.80.1.20, source port 50169. The SSH client has identified itself as "3SP_J2SSH_Hewlett_Packard_Company". According to Google, J2SSH might be a Java library for implementing SSH connections in Java applications.
Jun 14 16:01:02 sd1 sshd[1065]: SSH: Server;Ltype: Version;Remote: 200.80.1.20-50170;Protocol: 2.0;Client: 3SP_J2SSH_Hewlett_Packard_Company
Jun 14 16:01:03 sd1 sshd[1065]: Failed password for root from 200.80.1.20
And here's a third sshd child process (PID 1065) reporting another connection attempt from host 200.80.1.20, source port 50170. The client identifier is the same as in the previous case. After establishing a SSH connection, the client attempted to login as root but sent a wrong password.
And you said 200.80.1.20 is your test server?
Something is trying to login from testing to production as root, perhaps using a Java-based client application. Because there are three SSH connection attempts within about two seconds, it is likely that some software is making these connections in an automated fashion. (Although if the application has something like a "connect now" button, it's possible someone has simply clicked it two or three times instead of just once.)
According to most security standards, logging in directly as root is a bad thing. If your site policy requires keeping testing and production separate, nobody should not be logging from testing to production - at least not directly as root.
You should talk to the users of the test server to find out who is trying to login as root from test to production, and what s/he is trying to achieve with it. Then you should determine the correct way to achieve the desired results without violating your site policy.
Depending on what the user actually wants, this might require tasks like:
- creating a dedicated user account for application file transfer or issuing remote commands
- creating a user group and/or adjusting group memberships and file permissions to allow whatever the user is trying to do without being root
- if there is a legitimate requirement to execute commands in production as root, you might want to find a way for the user to run *only* the required commands (and nothing else) as root.
MK
MK
