CHECK_NRPE: Error - Failed to complete SSL handshake

Question

I have an NRPE daemon process running under xinetd on an amazon ec2 instance and a nagios server on my local machine.

check_nrpe -H [amazon public IP] gives this error:

 CHECK_NRPE: Error - Could not complete SSL handshake. 

Both Nrpe are the same versions. Both compiled with this option:

 ./configure --with-ssl=/usr/bin/openssl --with-ssl-lib=/usr/lib/i386-linux-gnu/ 

"resolved host" contains my local IP address.

What could be the possible cause of this error?

Answer 1

To check if you have access to it, try a simple telnet at: port, ping or traceroute to see where it blocks.

 telnet IP port ping IP traceroute -p $port IP 

Also check on the destination server that the nrpe daemon is working correctly.

 netstat -at | grep nrpe 

You also need to check the versions of OpenSSL installed on both servers, as I saw that this interrupt checks on occasion using SSL confirmation!

Answer 2

If you are using nrpe as a service, make sure you have this line in nrpe.cfg on the client side:

 # example 192. IP, yours will probably differ allowed_hosts=127.0.0.1,192.168.1.100 

You say that this is done, however, if you use nrpe under xinetd, be sure to edit the only_from directive in the /etc/xinetd.d/nrpe file.

Remember to restart the xinetd service:

 service xinetd restart 

Answer 3

@jgritty was right. you must edit the nrpe.cfg and nrpe configuration files to provide access to the master nagios server:

 vim /usr/local/nagios/etc/nrpe.cf allowed_hosts=127.0.0.1,172.16.16.150 

and

 vim /etc/xinetd.d/nrpe only_from= 127.0.0.1 172.16.16.150 

Answer 4

This is a few error message for NRPE. Check the firewall rules and make sure the port is open. Also try disabling SELinux and see if this allows connection. This is probably not a SSL problem, but a connection failure problem.

Answer 5

check /var/sys/system.log . In my case, it turned out that my monitored IP was set to something else than the one I installed in the nrpe.cfg file. However, I do not know the reasons for this change.

Answer 6

It looks like you are using the Nagios server in a virtual machine on a host-only network. If so, this will stop any external access. Make sure you have NAT or a bridged network.

Answer 7

Make sure you reload the Nagios Client plugin.

Answer 8

I am using nrpe using the xinetd service.

Also make sure (in addition to the above basic steps) that your nagios user is authenticated properly. In my case:

 Jun 6 15:05:52 gse2 xinetd[33237]: **Unknown user: nagios**<br>[file=/etc/xinetd.d/nrpe] [line=9] Jun 6 15:05:52 gse2 xinetd[33237]: Error parsing attribute user - DISABLING SERVICE [file=/etc/xinetd.d/nrpe] [line=9] Jun 6 15:05:52 gse2 xinetd[33237]: **Unknown group: nagios**<br>[file=/etc/xinetd.d/nrpe] [line=10] Jun 6 15:05:52 gse2 xinetd[33237]: Error parsing attribute group - DISABLING SERVICE [file=/etc/xinetd.d/nrpe] [line=10] Jun 6 15:05:52 gse2 xinetd[33237]: Service nrpe missing attribute user - DISABLING 

Displayed in / var / log messages.
At first it eluded me, but then I checked the ypbind service and found that it was not running.
After starting ypbind, the user and the nagios group were authenticated, the error disappeared.

Answer 9

some cases of nagios-nrpe-server rebooting ribs do not help, because the process was not killed or it was not restarted properly.

just run it manually and run.

Answer 10

Communication error with msg SSL communication. In addition, you must assign allow_host.

your nagios server is in a local language with a type C IP address such as 192.168.xxxx

when the target monitored server calls ssl msg to your local nagios server, the message must first go to your public IP address of your line, the message cannot go through the public IP address of your nagios server, which is internal.

you need NAT to forward the SSL message from the target server to the nagios internal server.

Or you better use the “GET” method, which simply receives a monitor message from the nagios client side, such as SNMP, to remotely monitor the local resource of Linux servers.

The need for SSL feedback in a double direction.

Best wishes

Answer 11

For me, the following is specified in the /etc/nagios/nrpe.cfg file on the client:

 dont_blame_nrpe=1 

This is the ubuntu 16.04 machine. For other possible problems, I recommend looking at nrpe logs. Here is a good article for setting up magazines.

Answer 12

If you are using Debian 9, there is a known issue regarding this issue caused by OpenSSL's failure to support the NRPE method to use to initiate anonymous SSL connections.

The problem seems to be fixed , but the fix has not yet been included in the official packages.

There is currently no reliable operation.

Answer 13

check the configuration in /etc/xinetd.d/nrpe and check the server IP address. If it shows only_from = 127.0.0.1, change it to the server IP address.

Answer 14

So many answers, none of them asked the reason why I ran into this problem.

It turns out that nagios has terrible support for cross-versions, and this was due to the fact that I had a “client” version 2 (controlled machine) and a “server” version 3 (controlling machine).

After I upgraded the client to version 3, the problem disappeared and I could run check_nrpe -H [client IP] without any problems.

Please note that I am not sure that the client / server are the correct terms with nagios, since in the case of an NRPE call, the server is really the machine being called, but I got distracted.