Support forum for Nagios Core, Nagios Plugins, NCPA, NRPE, NSCA, NDOUtils and more. Engage with the community of users including those using the open source solutions.
nihvel wrote:I only have one more question:
How come if I edit nrpe.cfg with the path of certificates, the command ./check_nrpe -H ip -c command does not work resulting in an ssl handshake error, and when I send the command with certificates option included, it does?
jfrickson wrote:check_nrpe does not read the nrpe.cfg. It only uses command-line arguments. That might explain some of your problems if you were expecting check_nrpe to use what is in the config file.
nihvel wrote:I only have one more question:
How come if I edit nrpe.cfg with the path of certificates, the command ./check_nrpe -H ip -c command does not work resulting in an ssl handshake error, and when I send the command with certificates option included, it does?
check_nrpe does not read the nrpe.cfg. It only uses command-line arguments. That might explain some of your problems if you were expecting check_nrpe to use what is in the config file.
nihvel wrote:Ok, two more questions:
I know that this is silly but I need to report everything to colleagues. I can't see crypted packets from wireshark. How can I check and really show to them that the connection is ciphered? Because just sayin "it use certificate trust me it is" does not help me. I need to show that it really is. And wireshark is not helping me because all I see is TCP. Ok that a few "plain text" packages there will always be, but I do not see any tls/ssl
Two things you can tell them. First, all NRPE communication between the client and the server is plain text. If you run a check_load command, the output will be something like
OK - load average: 0.09, 0.16, 0.14|load1=0.090;0.750;1.500;0; load5=0.160;0.500;1.250;0; load15=0.140;0.250;1.000;0;
If you don't see any packets with that kind of text, then it's encrypted.
Second, if you have ssl_logging=0x2f turned on in the nrpe.cfg file and -s 0x2f on the check_nrpe command line, syslog will tell you. For example, below is the log entries from a check I ran. Notice in particular the line Remote - TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384. That says it's communicating using TLSv1/SSLv3 and the connection is encrypted with the cipher DHE-RSA-AES256-GCM-SHA384. The RSA part indicates it's public-key encryption. AES256 means it's using 256-bit AES encryption. SHA384 means it's using a 384-bit SHA hash. The details of both the client and server certificates is also shown.
Wonderful! And I have the same log too but at least I know now how to read it! Thank you!
Box293 wrote:
nihvel wrote:I only have one more question:
How come if I edit nrpe.cfg with the path of certificates, the command ./check_nrpe -H ip -c command does not work resulting in an ssl handshake error, and when I send the command with certificates option included, it does?
jfrickson wrote:check_nrpe does not read the nrpe.cfg. It only uses command-line arguments. That might explain some of your problems if you were expecting check_nrpe to use what is in the config file.
I'm sure this request is welcome! It all started also because I thought nrpe.cfg was the one and only way to configure the command check_nrpe, and that check_nrpe -options were just to troubleshoot.. Silly me!
You guys helped me a lot thank you again and since it's 24th today, Merry Christmas everybody!