Discussion:
check_ssh error
Lingenfelter, Troy Contractor
2014-09-10 14:52:08 UTC
Permalink
I'm running the check_ssh plugin from a RHEL6 Linux Server running NAGIOS XI. When running the check_ssh script from the Linux server to a remote Solaris 10 system I get the following in the /var/adm/messages log

sshd2[13600]: [ID 800047 local6.crit] fatal getpeername failed: Transport endpoint is not connected

I'm trying to determine what would be causing this error

Regards,
Troy Lingenfelter
Integration Specialist - Contractor
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Unix/Linux Platform Support Team
OTSO/IAC/DIIAS/MPEB/ULPST
Email: Troy.Lingenfelter-***@public.gmane.org<mailto:Troy.Lingenfelter-***@public.gmane.org>
Office #: 410-965-3026

IM Tickets:
Call: 1-877-697-4889
Provide with the reason for the ticket and the ULPST Office Code (527ULPST)

If no mistake have you made, yet losing you are ... a different game you should play.
--YODA
zep
2014-09-11 15:36:46 UTC
Permalink
I’m running the check_ssh plugin from a RHEL6 Linux Server running
NAGIOS XI. When running the check_ssh script from the Linux server to
a remote Solaris 10 system I get the following in the
/var/adm/messages log
Transport endpoint is not connected
I’m trying to determine what would be causing this error
Regards,
Troy Lingenfelter
Integration Specialist – Contractor
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I haven't seen anyone else answer this, so I'll take a stab. at a
guess, I'd think that the check_ssh script is causing the sshd to throw
that error becasue it's just connecting (in the TCP sense, as opposed to
at the application layer sense, sending handshake, et al). Nagios is
jus making sure something is there and then closing the connection,
which makes the solaris sshd server flip out just a little (or give you
some bread crumbs to know that someone's probing your ssh service, if
you prefer to look at it that way)

you could confirm by tailing the messages file on the solaris side and
then choose another box to run 'telnet <solaris server's name> 22' then use
control-] control-d to break and close the telnet session; I'd expect
the same error message to show up.

as far as not getting that error, the only things I could suggest would
be building a new check_ssh script/program and either use an
unprivileged user id with ssh keys (possibly bad, since you're sending
from a .gov address, seems likely to violate a security policy)
hardcoded password in an expect script (far worse, IMHO, but possibly
more difficult for auditors to find). or just stop checking ssh as a
service... or change some logging rules to ignore/filter that message..
or compiling a different server to run (that seems to be what's going on
for my prod servers; I can't reproduce that problem on solaris 10)
Loading...