CHECK_NRPE : Error : Connection Reset by Peer

[amitgupta19]

Did anyone got a chance to look into this?

[mbellerue]

Does this mean that there is something in the Server which is giving the SSL Error?
if yes, What could be the reason?

Because we already have the servers working without any error.

It means that there is something in the certificates that NRPE doesn't like. It could be on the Nagios side, or it could be on the remote server side. Since you have checks that are working, we can assume it is not on the Nagios side. You could compare the certificates on one of the working servers against the certificates on one of the non-working servers. You might find whatever key difference is throwing NRPE off.

It could be that the working servers are configured for enhanced security.
https://support.nagios.com/kb/article.php?id=519

[amitgupta19]

Can you guide me how to compare the Certificates of the 2 Servers?

Also i compared the Logs of a working server and a non working server:

Working Server:
NRPE Logs : No Errors.
OS Logs: "Dec 27 14:14:36 localhost nrpe[27313]: Error: (!log_opts) Could not complete SSL handshake with xxx.xxx.xxx.xxx: 5"


Non Working Server:
NRPE Logs: "Error: (!log_opts) Could not complete SSL handshake with xxx.xxx.xxx.xxx: 5"
OS Logs: "Dec 27 16:06:37 xxxxx-xxxxxxxx24 nrpe[30182]: Error: (!log_opts) Could not complete SSL handshake with xxx.xxx.xxx.xxx: 5"

Both the above logs seems to be contradicting, can you suggest?

Regards
Amit

[mbellerue]

Can you run this command against a working and non-working host?

Code: Select all

/usr/local/nagios/libexec/check_nrpe -H <IPaddress>

That will give you the version number of the NRPE agent running on the hosts. It may be that we need to upgrade the NRPE agent, the check_nrpe plugin, or both.

When the NRPE agent and plugin are compiled, they automatically create certs and keys, and those are baked in to the executable.

[amitgupta19]

Please find here with the output:

Non Working Server-------------

[amgupta@xxxxxxxx libexec]$ sudo ./check_nrpe -H xxx.xxx.xxx.xxx
[sudo] password for amgupta:
CHECK_NRPE: Error - Could not connect to xxx.xxx.xxx.xxx: Connection reset by peer

Working Server-----

[amgupta@xxxxxxxxx libexec]$ sudo ./check_nrpe -H xxx.xxx.xxx.xxx
NRPE v3.2.1

============================================================
Also i would like to inform you that above non working server was cloned from a server which is reporting correctly in Nagios.

[mbellerue]

Is there a firewall running on the remote server? Is that a Windows or Linux machine?

[amitgupta19]

I don't think that there is a firewall running on the remote server:


I am able to telnet on the port 5666 from the Nagios Server
===================================================
[amgupta@xxxxxxxs01 ~]$ telnet xxx.xxxx.xxx.xxx 5666
Trying xxx.xxxx.xxx.xxx...
Connected to xxx.xxxx.xxx.xxx.
Escape character is '^]'.
^C


Connection closed by foreign host.
[amgupta@xxxxxxxs01 ~]$
===============================================================

Please Note that it is a Linux Server.

[mbellerue]

Ah, I bet it's running under xinet.d. Can you post the output of cat /etc/xinet.d/nrpe

That has a line in it, only_from where your Nagios server's IP needs to be listed (space separated). If it's running under xinet.d, the entry in the nrpe.cfg file is not used.

[amitgupta19]

It is not using the xinet.d please find here with the output

[xxxxxxx@dmz16-labxxxd24 ~]$ cat /etc/xinet.d/nrpe
cat: /etc/xinet.d/nrpe: No such file or directory
[xxxxxxx@dmz16-labxxxd24 ~]$

Also i am sending the allowed Host from the nrpe.cfg file

[xxxxxxx@dmz16-labxxxd24 ~]$ sudo cat /usr/local/nagios/etc/nrpe.cfg | grep -i allowed
# ALLOWED HOST ADDRESSES
# that are allowed to talk to the NRPE daemon. Network addresses with a bit mask
#allowed_hosts=127.0.0.1,::1
allowed_hosts=127.0.0.1,yyy.yyy.yyy.yyy,xxx.xxx.xxx.xxx


xxx.xxx.xxx.xxx --- This is the Nagios Server IP.


Regards
Amit

[mbellerue]

Does the Nagios IP show up in /etc/hosts.allow on either the working or non-working servers?

What about the yyy.yyy.yyy.yyy IP? Is that another Linux machine? Could we put the check_nrpe binary on that machine temporarily and try accessing the server from it?