ladinek commented 7 years ago

I installed Nagios on Raspberry Pi. I am already running lot of Nagios3 instances on x86 Debian Wheezy (7) and Jessie (8). Now I am trying to nagios-nrpe-plugin against NSCLIENT++ on Windows machines. The repository package version of check_nrpe on Raspberry, identically on x64 Stretch, is 3.0.1. However, when I run check_nrpe from x64 box, everything is OK, but from Raspberry, I get error On the NSCLIENT side, I have this config:

ssl options = 
verify mode = none
insecure = true

Executing root@raspberrypi:~# /usr/lib/nagios/plugins/check_nrpe -H 192.168.32.35 I get error CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with 192.168.32.35: 1 and on the Windows NSCLIENT side, running NSCP TEST, I get this error:

D       nrpe Accepting connection from: 192.168.32.32, count=1
E       nrpe Failed to establish secure connection: sslv3 alert handshake failure

When I try - n option,

root@raspberrypi:~# /usr/lib/nagios/plugins/check_nrpe -H 192.168.32.35 -n
CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected).

and on the Windows side,

D       nrpe Accepting connection from: 192.168.32.32, count=1
E       nrpe Failed to establish secure connection: unknown protocol: 252
                    D:\source\nscp\include\socket/connection.hpp:243

Running the same from the x64-based Debian Stretch works normally. It is show-stopper for using Nagios on Raspberry Pi. I also tried downloading and compiling both 2.15 version and 3.20 version, with similar results. Can this be liitle/big endian issue or something like that?

MartinEgli commented 7 years ago

Same problem with 3.2.1 on my Raspi.

NRPE Plugin for Nagios Version: 3.2.1

./check_nrpe -H 192.168.105.254 CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with 192.168.105.254: 1

./check_nrpe -H 192.168.105.254 -n CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected).

ladinek commented 7 years ago

Meanwhile I discovered workaround, set request size on both sides exactly the same, or – if you have lot of nsclients and do not wish to visit them all – set the request size to 1024. I had to add parameters -2 -P 1024 and the working version is the version from the repository, package name nagios-nrpe-plugin.

Regards,

Vladimir

From: MartinEgli [mailto:notifications@github.com] Sent: Monday, November 20, 2017 9:24 AM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

Same problem with 3.2.1 on my Raspi.

NRPE Plugin for Nagios Version: 3.2.1

./check_nrpe -H 192.168.105.254 CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with 192.168.105.254: 1

./check_nrpe -H 192.168.105.254 -n CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345622838, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwOxli_0Xq1OhiQlCauaXkn70RipXxks5s4TcIgaJpZM4QLIx9.

MartinEgli commented 7 years ago

Unfortunately it does not work!

./check_nrpe -V

NRPE Plugin for Nagios Copyright (c) 1999-2008 Ethan Galstad (nagios@nagios.org) Version: 3.0.1 Last Modified: 09-08-2016 License: GPL v2 with exemptions (-l for more info) SSL/TLS Available: OpenSSL 0.9.6 or higher required

./check_nrpe -H 192.168.101.254 -2 -P 1024 CHECK_NRPE: Response packet had invalid CRC32.

./check_nrpe -H 192.168.101.254 -2 -P 1024 -n CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected).

./checknrpe -V NRPE Plugin for Nagios Version: 3.2.1

./check_nrpe -H 192.168.101.254 -2 -P 1024 CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with 192.168.101.254: 1

./check_nrpe -H 192.168.101.254 -2 -P 1024 -n CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected).

ladinek commented 7 years ago

pi@raspberrypi:~ $ /usr/lib/nagios/plugins/check_nrpe -H 192.168.32.34 -2 -P 1024 I (0.4.3.143 2015-04-29) seem to be doing fine... pi@raspberrypi:~ $ /usr/lib/nagios/plugins/check_nrpe -H 192.168.32.34 -2 -P 1023 CHECK_NRPE STATE CRITICAL: Socket timeout after 10 seconds. pi@raspberrypi:~ $ /usr/lib/nagios/plugins/check_nrpe -H 192.168.32.34 -2 -P 1025 CHECK_NRPE: Response packet had invalid CRC32.

Do you use encryption? I have: [/settings/NRPE/server]

; VERIFY MODE - Comma separated list of verification flags to set on the SSL socket. default-workarounds Various workarounds for what I understand to be broken ssl implementations no-sslv2 Do not use the SSLv2 protocol. no-sslv3 Do not use the SSLv3 protocol. no-tlsv1 Do not use the TLSv1 protocol. single-dh-use Always create a new key when using temporary/ephemeral DH parameters. This option must be used to prevent small subgroup attacks, when the DH parameters were not generated using "strong" primes (e.g. when using DSA-parameters). ssl options =

; VERIFY MODE - Comma separated list of verification flags to set on the SSL socket. none The server will not send a client certificate request to the client, so the client will not send a certificate. peer The server sends a client certificate request to the client and the certificate returned (if any) is checked. fail-if-no-cert if the client did not return a certificate, the TLS/SSL handshake is immediately terminated. This flag must be used together with peer. peer-cert Alias for peer and fail-if-no-cert. workarounds Various bug workarounds. single Always create a new key when using tmp_dh parameters. client-once Only request a client certificate on the initial TLS/SSL handshake. This flag must be used together with verify-peer verify mode = none

; ALLOW INSECURE CHIPHERS and ENCRYPTION - Only enable this if you are using legacy check_nrpe client. insecure = true allow arguments = true allow nasty characters = true

What version of nsclient++ do you use? I use 4.3-4.4 series of NSCLIENT++. Try set the request size on both sides to the same value (do not forget restart NSCP service after changing nsclient.ini, or try to observe test mode – in the CMD elevated prompt try NSCP TEST

https://docs.nsclient.org/reference/client/NRPEServer/#/settings/NRPE/server_payload%20length

From: MartinEgli [mailto:notifications@github.com] Sent: Monday, November 20, 2017 12:05 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

Unfortunately it does not work!

./check_nrpe -V

NRPE Plugin for Nagios Copyright (c) 1999-2008 Ethan Galstad (nagios@nagios.orgmailto:nagios@nagios.org) Version: 3.0.1 Last Modified: 09-08-2016 License: GPL v2 with exemptions (-l for more info) SSL/TLS Available: OpenSSL 0.9.6 or higher required

./check_nrpe -H 192.168.101.254 -2 -P 1024 CHECK_NRPE: Response packet had invalid CRC32.

./check_nrpe -H 192.168.101.254 -2 -P 1024 -n CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected).

./checknrpe -V NRPE Plugin for Nagios Version: 3.2.1

./check_nrpe -H 192.168.101.254 -2 -P 1024 CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with 192.168.101.254: 1

./check_nrpe -H 192.168.101.254 -2 -P 1024 -n CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345663698, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO4nvFKfjzefFs38Fz6SlWH0h-5Zjks5s4VzPgaJpZM4QLIx9.

MartinEgli commented 7 years ago

I do not use encryption, yet. "-n"

On my "Old Raspi Jessy" the "./check_nrpe -H 192.168.101.254" works with out problems.

hedenface commented 7 years ago

Just tested this with my machines. Windows 7 x64 running 0.4.4.23. Linux mint running NRPE 3.2.1, configured with the flags:

./configure --enable-command-args

Here are the relevant sections from nsclient.ini:

; A list of modules.
[/modules]

; NRPEServer - A server that listens for incoming NRPE connection and processes incoming requests.
NRPEServer = 1

[/settings/NRPE/server]

; ENABLE SSL ENCRYPTION - This option controls if SSL should be enabled.
use ssl = 0

; ALLOW INSECURE CHIPHERS and ENCRYPTION - Only enable this if you are using legacy check_nrpe client.
insecure = 1

; COMMAND ALLOW NASTY META CHARS - This option determines whether or not the we will allow clients to specify nasty (as in |`&><'"\[]{}) characters in arguments.
allow nasty characters = 0

; COMMAND ARGUMENT PROCESSING - This option determines whether or not the we will allow clients to specify arguments to commands that are executed.
allow arguments = 1

; PORT NUMBER - Port to use for NRPE.
port = 5666

; EXTENDED RESPONSE - Send more then 1 return packet to allow response to go beyond payload size (requires modified client if legacy is true this defaults to false).
extended response = 1

And finally, the check command I ran:

./check_nrpe -H 192.168.3.15 -n

With the output:

I (0.4.4.23 2016-04-05) seem to be doing fine...

That said, NSClient isn't our software and isn't something I can spend too much time debugging. Have you looked into using NCPA as a replacement? :)

MartinEgli commented 7 years ago

My Servers are a Raspis with Raspbian Jessy and Sketch, with Icinga2
(Check_nrpe) Version 2.15 Jessy and 3.2.1 Sketch. The Clients are ALIX with IPFire (Linux) with nagios and nagios_nrpe (server) Version 2.15.

ladinek commented 7 years ago

Hmm, I tried both 2.15 client from backports, and latest 3.2.1, no success. Only version I got to work was 3.0.1 from Stretch package.

From: MartinEgli [mailto:notifications@github.com] Sent: Monday, November 20, 2017 1:32 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

My Servers are a Raspis with Raspbian Jessy and Sketch, with Icinga2 (Check_nrpe) Version 2.15 Jessy and 3.2.1 Sketch. The Clients are ALIX with IPFire (Linux) with nagios and nagios_nrpe (server) Version 2.15.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345682501, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO9couN9oJEa4T6hJ95m4hYV3Uxw7ks5s4XEsgaJpZM4QLIx9.

MartinEgli commented 7 years ago

Is check_nrpe with Stretck with no encription possible?

ladinek commented 7 years ago

Yes, I am using it without encryption – I think –n parameter, but with portion of nsclient.ini from my configuration it is not necessary. However, testing –n parameter from check_nrpe did not help (errors regarding encryption), I think there is some error with negotiation.

Regards,

Vladimir

From: MartinEgli [mailto:notifications@github.com] Sent: Monday, November 20, 2017 2:18 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

Is check_nrpe with Stretck with no encription possible?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345692613, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO-SUidi0C_CT_0lPEyK7xC0btKKSks5s4XvwgaJpZM4QLIx9.

ladinek commented 7 years ago

On the x86 Linux everything runs OK. I ran it side by side, with the same versions of Debian Linux on both platforms (x64 on the PC and ARM on Raspberry). On the ARM-based Raspberry we are getting errors we are talking about. Couldnot be this for example some little endian/big endian numeric representation issue on the request side? I got it working if and only if I forced fixed request size and v2 protocol (-2 and –P 1024 options).

Vladimir

From: Bryan Heden [mailto:notifications@github.com] Sent: Monday, November 20, 2017 1:22 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

Just tested this with my machines. Windows 7 x64 running 0.4.4.23. Linux mint running NRPE 3.2.1, configured with the flags:

./configure --enable-command-args

Here are the relevant sections from nsclient.ini:

; A list of modules.

[/modules]

; NRPEServer - A server that listens for incoming NRPE connection and processes incoming requests.

NRPEServer = 1

[/settings/NRPE/server]

; ENABLE SSL ENCRYPTION - This option controls if SSL should be enabled.

use ssl = 0

; ALLOW INSECURE CHIPHERS and ENCRYPTION - Only enable this if you are using legacy check_nrpe client.

insecure = 1

; COMMAND ALLOW NASTY META CHARS - This option determines whether or not the we will allow clients to specify nasty (as in |`&><'"[]{}) characters in arguments.

allow nasty characters = 0

; COMMAND ARGUMENT PROCESSING - This option determines whether or not the we will allow clients to specify arguments to commands that are executed.

allow arguments = 1

; PORT NUMBER - Port to use for NRPE.

port = 5666

; EXTENDED RESPONSE - Send more then 1 return packet to allow response to go beyond payload size (requires modified client if legacy is true this defaults to false).

extended response = 1

And finally, the check command I ran:

./check_nrpe -H 192.168.3.15 -n

With the output:

I (0.4.4.23 2016-04-05) seem to be doing fine...

That said, NSClient isn't our software and isn't something I can spend too much time debugging. Have you looked into using NCPAhttps://github.com/nagiosenterprises/ncpa as a replacement? :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345680504, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO8Efx0LCqxNg2Y436PcArMwQ5SRxks5s4W78gaJpZM4QLIx9.

ladinek commented 7 years ago

I forgot to say, if I run 3.0.1 check_nrpe on Raspberry with option –n (and I have encryption disabled), I receive another error: pi@raspberrypi:~ $ /usr/lib/nagios/plugins/check_nrpe -H 192.168.32.34 -2 -P 1024 -n CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected).

From: Bryan Heden [mailto:notifications@github.com] Sent: Monday, November 20, 2017 1:22 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

Just tested this with my machines. Windows 7 x64 running 0.4.4.23. Linux mint running NRPE 3.2.1, configured with the flags:

./configure --enable-command-args

Here are the relevant sections from nsclient.ini:

; A list of modules.

[/modules]

; NRPEServer - A server that listens for incoming NRPE connection and processes incoming requests.

NRPEServer = 1

[/settings/NRPE/server]

; ENABLE SSL ENCRYPTION - This option controls if SSL should be enabled.

use ssl = 0

; ALLOW INSECURE CHIPHERS and ENCRYPTION - Only enable this if you are using legacy check_nrpe client.

insecure = 1

; COMMAND ALLOW NASTY META CHARS - This option determines whether or not the we will allow clients to specify nasty (as in |`&><'"[]{}) characters in arguments.

allow nasty characters = 0

; COMMAND ARGUMENT PROCESSING - This option determines whether or not the we will allow clients to specify arguments to commands that are executed.

allow arguments = 1

; PORT NUMBER - Port to use for NRPE.

port = 5666

; EXTENDED RESPONSE - Send more then 1 return packet to allow response to go beyond payload size (requires modified client if legacy is true this defaults to false).

extended response = 1

And finally, the check command I ran:

./check_nrpe -H 192.168.3.15 -n

With the output:

I (0.4.4.23 2016-04-05) seem to be doing fine...

That said, NSClient isn't our software and isn't something I can spend too much time debugging. Have you looked into using NCPAhttps://github.com/nagiosenterprises/ncpa as a replacement? :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345680504, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO8Efx0LCqxNg2Y436PcArMwQ5SRxks5s4W78gaJpZM4QLIx9.

hedenface commented 7 years ago

Are you able to compile from source on the ras to test? Ensure NSClient SSL is disabled, and then run ./configure with --disable-ssl and --enable-command-args.

ladinek commented 7 years ago

I already compiled the 3.2.1 version, so I know it is possible. So I will try compiling with options as you advice, however probably not today. I will let you know.

From: Bryan Heden [mailto:notifications@github.com] Sent: Monday, November 20, 2017 2:37 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

Are you able to compile from source on the ras to test? Ensure NSClient SSL is disabled, and then run ./configure with --disable-ssl and --enable-command-args.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345697380, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO54icf5stEF_uXFxUREh2azpl-2Zks5s4YCOgaJpZM4QLIx9.

MartinEgli commented 7 years ago

Yes!

My console output: Sorry for the german stuff.

./configure --disable-ssl --enable-command-args checking for a BSD-compatible install... /usr/bin/install -c checking what the operating system is ... linux checking what the distribution type is ... debian checking what init system is being used ... systemd checking what inetd is being used ... systemd checking for which paths to use ... default checking for which init file to use ... default-service checking for which inetd files to use ... default-socket checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether make sets $(MAKE)... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking whether time.h and sys/time.h may both be included... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking ctype.h usability... yes checking ctype.h presence... yes checking for ctype.h... yes checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking for inttypes.h... (cached) yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking for stdint.h... (cached) yes checking for strings.h... (cached) yes checking for string.h... (cached) yes checking syslog.h usability... yes checking syslog.h presence... yes checking for syslog.h... yes checking tcpd.h usability... no checking tcpd.h presence... no checking for tcpd.h... no checking for unistd.h... (cached) yes checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking socket.h usability... no checking socket.h presence... no checking for socket.h... no checking for sys/types.h... (cached) yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking for sys/wait.h... (cached) yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for sys/stat.h... (cached) yes checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking for an ANSI C-conforming const... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for mode_t... yes checking for pid_t... yes checking for size_t... yes checking return type of signal handlers... void checking for uid_t in sys/types.h... yes checking type of array argument to getgroups... gid_t checking size of int... 4 checking size of short... 2 checking size of long... 4 checking for uint32_t... yes checking for u_int32_t... yes checking for int32_t... yes checking for struct sockaddr_storage... yes checking for seteuid... yes checking for va_copy... yes checking for vsnprintf... yes checking for snprintf... yes checking for asprintf... yes checking for vasprintf... yes checking for C99 vsnprintf... yes checking for getopt_long... yes checking for main in -lnsl... yes checking for socket in -lsocket... no checking for main in -lwrap... no checking for strdup... yes checking for strstr... yes checking for strtoul... yes checking for strtok_r... yes checking for initgroups... yes checking for closesocket... no checking for sigaction... yes checking for scandir... yes checking for socklen_t... yes checking for type of socket size... size_t checking for perl... /usr/bin/perl configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating nrpe.spec config.status: creating uninstall config.status: creating sample-config/nrpe.cfg config.status: creating startup/bsd-init config.status: creating startup/debian-init config.status: creating startup/default-init config.status: creating startup/default-inetd config.status: creating startup/default-service config.status: creating startup/default-socket config.status: creating startup/default-socket-svc config.status: creating startup/default-xinetd config.status: creating startup/mac-init.plist config.status: creating startup/mac-inetd.plist config.status: creating startup/newbsd-init config.status: creating startup/openbsd-init config.status: creating startup/openrc-conf config.status: creating startup/openrc-init config.status: creating startup/solaris-init.xml config.status: creating startup/solaris-inetd.xml config.status: creating startup/tmpfile.conf config.status: creating startup/upstart-init config.status: creating startup/rh-upstart-init config.status: creating include/common.h config.status: creating include/config.h

Configuration summary for nrpe 3.2.1 2017-09-01 :

General Options:

NRPE port: 5666 NRPE user: nagios NRPE group: nagios Nagios user: nagios Nagios group: nagios

Review the options above for accuracy. If they look okay, type 'make all' to compile the NRPE daemon and client or type 'make' to get a list of make options.

make all cd ./src/; make make[1]: Verzeichnis „/tmp/nrpe/nrpe3.2.1/src“ wird betreten gcc -g -O2 -DHAVE_CONFIG_H -I ../include -I ./../include -o nrpe ./nrpe.c ./utils.c ./acl.c -lnsl gcc -g -O2 -DHAVE_CONFIG_H -I ../include -I ./../include -o check_nrpe ./check_nrpe.c ./utils.c -lnsl make[1]: Verzeichnis „/tmp/nrpe/nrpe3.2.1/src“ wird verlassen

Compile finished

You can now continue with the installation or upgrade process.

Read the PDF documentation (docs/NRPE.pdf) for information on the next steps you should take to complete the installation or upgrade.

make install cd ./src/; make install make[1]: Verzeichnis „/tmp/nrpe/nrpe3.2.1/src“ wird betreten make install-plugin make[2]: Verzeichnis „/tmp/nrpe/nrpe3.2.1/src“ wird betreten /usr/bin/install -c -m 755 -d /usr/local/nagios/bin /usr/bin/install -c -m 755 ../uninstall /usr/local/nagios/bin/nrpe-uninstall /usr/bin/install -c -m 775 -o nagios -g nagios -d /usr/local/nagios/libexec /usr/bin/install -c -m 775 -o nagios -g nagios -d /usr/local/nagios/libexec /usr/bin/install -c -m 775 -o nagios -g nagios check_nrpe /usr/local/nagios/libexec make[2]: Verzeichnis „/tmp/nrpe/nrpe3.2.1/src“ wird verlassen make install-daemon make[2]: Verzeichnis „/tmp/nrpe/nrpe3.2.1/src“ wird betreten /usr/bin/install -c -m 755 -d /usr/local/nagios/bin /usr/bin/install -c -m 755 ../uninstall /usr/local/nagios/bin/nrpe-uninstall /usr/bin/install -c -m 755 nrpe /usr/local/nagios/bin /usr/bin/install -c -m 755 -d /usr/lib/tmpfiles.d /usr/bin/install -c -m 644 ../startup/tmpfile.conf /usr/lib/tmpfiles.d/nrpe.conf make[2]: Verzeichnis „/tmp/nrpe/nrpe3.2.1/src“ wird verlassen make[1]: Verzeichnis „/tmp/nrpe/nrpe3.2.1/src“ wird verlassen

Test output:

root@icinga:/usr/local/nagios/libexec# ./check_nrpe -H 192.168.101.254 -n CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected). root@icinga:/usr/local/nagios/libexec# ./check_nrpe -H 192.168.101.254 CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected). root@icinga:/usr/local/nagios/libexec#

hedenface commented 7 years ago

Show me your nsclient.ini file in its entirety, please. Sanitize where necessary.

MartinEgli commented 7 years ago

Where can I find these?

hedenface commented 7 years ago

On your Windows workstation/server - the configuration file you're using for nsclient.

MartinEgli commented 7 years ago

Sorry no Windows.

hedenface commented 7 years ago

This whole thread was in regards to nsclient not working with check_nrpe.

MartinEgli commented 7 years ago

Sorry title is "check_nrpe not working on Raspberry PI". New Issues?

ladinek commented 7 years ago

Here is excerpt from mine: But as I said before, from Intel-based linux it works. I spent quite a lot of time with this, because Raspberry is ideal machine for Nagios (we have VMWare infrastructure on customer´s sites, and until now we use Nagios on virtual machine). Now we are trying to have „hardware“ monitoring solution not being dependent on running VMWare, and impossibilty of monitoring by check_nrpe was show-stopper. As I said before, the only working solutions was adding -2 –P 1024 to the command line, not touching Windows machines with nsclient (with my typical configuration shown below).

If you want to fill this file with all avalible options run the following command:

nscp settings --generate --add-defaults --load-all

If you want to activate a module and bring in all its options use:

nscp settings --activate-module --add-defaults

For details run: nscp settings --help

; Undocumented section [/settings/default]

; ALLOWED HOSTS - A comaseparated list of allowed hosts. You can use netmasks (/ syntax) or * to create ranges. allowed hosts = 192.168.32.32

; Undocumented section [/settings/NRPE/server]

; VERIFY MODE - Comma separated list of verification flags to set on the SSL socket. default-workarounds Various workarounds for what I understand to be broken ssl implementations no-sslv2 Do not use the SSLv2 protocol. no-sslv3 Do not use the SSLv3 protocol. no-tlsv1 Do not use the TLSv1 protocol. single-dh-use Always create a new key when using temporary/ephemeral DH parameters. This option must be used to prevent small subgroup attacks, when the DH parameters were not generated using "strong" primes (e.g. when using DSA-parameters). ssl options =

; VERIFY MODE - Comma separated list of verification flags to set on the SSL socket. none The server will not send a client certificate request to the client, so the client will not send a certificate. peer The server sends a client certificate request to the client and the certificate returned (if any) is checked. fail-if-no-cert if the client did not return a certificate, the TLS/SSL handshake is immediately terminated. This flag must be used together with peer. peer-cert Alias for peer and fail-if-no-cert. workarounds Various bug workarounds. single Always create a new key when using tmp_dh parameters. client-once Only request a client certificate on the initial TLS/SSL handshake. This flag must be used together with verify-peer verify mode = none

; ALLOW INSECURE CHIPHERS and ENCRYPTION - Only enable this if you are using legacy check_nrpe client. insecure = true allow arguments = true allow nasty characters = true

; Undocumented section [/modules]

; NRPEServer - A server that listens for incoming NRPE connection and processes incoming requests. NRPEServer = 1

; CheckSystem - Various system related checks, such as CPU load, process state, service state memory usage and PDH counters. CheckSystem = 1

; NSClientServer - A server that listens for incoming check_nt connection and processes incoming requests. NSClientServer = 1

; CheckExternalScripts - Execute external scripts CheckExternalScripts = 1

; CheckHelpers - Various helper function to extend other checks. CheckHelpers = 1

; CheckEventLog - Check for errors and warnings in the event log. CheckEventLog = 1

; CheckNSCP - Use this module to check the healt and status of NSClient++ it self CheckNSCP = 1

; CheckDisk - CheckDisk can check various file and disk related things. CheckDisk = 1

From: Bryan Heden [mailto:notifications@github.com] Sent: Monday, November 20, 2017 3:27 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

On your Windows workstation/server - the configuration file you're using for nsclient.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345710909, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwOx4FrKU6YC8LQULq1aF5pXtVxos6ks5s4Yw3gaJpZM4QLIx9.

ladinek commented 7 years ago

Yes, Martin has Linux machines and when asked from Raspi box by check_nrpe, they answer with the same errors like mine with Windows/nsclient configuration. Problem is definitely with ARM-based check-nrpe-client.

From: Bryan Heden [mailto:notifications@github.com] Sent: Monday, November 20, 2017 3:30 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

This whole thread was in regards to nsclient not working with check_nrpe.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345711709, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO6aUrqEuUGpEq2lDK-wnJl5NldQTks5s4YzWgaJpZM4QLIx9.

MartinEgli commented 7 years ago

My config on ipfire Linux

nrpe.cfg

#############################################################################
# Sample NRPE Config File 
# Written by: Ethan Galstad (nagios@nagios.org)
# 
# Last Modified: 11-23-2007
#
# NOTES:
# This is a sample configuration file for the NRPE daemon.  It needs to be
# located on the remote host that is running the NRPE daemon, not the host
# from which the check_nrpe client is being executed.
#############################################################################

# LOG FACILITY
# The syslog facility that should be used for logging purposes.

log_facility=daemon

# PID FILE
# The name of the file in which the NRPE daemon should write it's process ID
# number.  The file is only written if the NRPE daemon is started by the root
# user and is running in standalone mode.
pid_file=/var/run/nrpe.pid
# PORT NUMBER
# Port number we should wait for connections on.
# NOTE: This must be a non-priviledged port (i.e. > 1024).
# NOTE: This option is ignored if NRPE is running under either inetd or xinetd
server_port=5666
# SERVER ADDRESS
# Address that nrpe should bind to in case there are more than one interface
# and you do not want nrpe to bind on all interfaces.
# NOTE: This option is ignored if NRPE is running under either inetd or xinetd
#server_address=127.0.0.1
# NRPE USER
# This determines the effective user that the NRPE daemon should run as.  
# You can either supply a username or a UID.
# 
# NOTE: This option is ignored if NRPE is running under either inetd or xinetd
nrpe_user=nobody
# NRPE GROUP
# This determines the effective group that the NRPE daemon should run as.  
# You can either supply a group name or a GID.
# 
# NOTE: This option is ignored if NRPE is running under either inetd or xinetd
nrpe_group=users
# ALLOWED HOST ADDRESSES
# This is an optional comma-delimited list of IP address or hostnames 
# that are allowed to talk to the NRPE daemon. Network addresses with a bit mask
# (i.e. 192.168.1.0/24) are also supported. Hostname wildcards are not currently 
# supported.
#
# Note: The daemon only does rudimentary checking of the client's IP
# address.  I would highly recommend adding entries in your /etc/hosts.allow
# file to allow only the specified host to connect to the port
# you are running this daemon on.
#
# NOTE: This option is ignored if NRPE is running under either inetd or xinetd
#allowed_hosts=127.0.0.1
allowed_hosts=127.0.0.1,192.168.110.12,192.168.110.0/24,192.168.101.10
# COMMAND ARGUMENT PROCESSING
# This option determines whether or not the NRPE daemon will allow clients
# to specify arguments to commands that are executed.  This option only works
# if the daemon was configured with the --enable-command-args configure script
# option.  
#
# *** ENABLING THIS OPTION IS A SECURITY RISK! *** 
# Read the SECURITY file for information on some of the security implications
# of enabling this variable.
#
# Values: 0=do not allow arguments, 1=allow command arguments
dont_blame_nrpe=0
# COMMAND PREFIX
# This option allows you to prefix all commands with a user-defined string.
# A space is automatically added between the specified prefix string and the
# command line from the command definition.
#
# *** THIS EXAMPLE MAY POSE A POTENTIAL SECURITY RISK, SO USE WITH CAUTION! ***
# Usage scenario: 
# Execute restricted commmands using sudo.  For this to work, you need to add
# the nagios user to your /etc/sudoers.  An example entry for alllowing 
# execution of the plugins from might be:
#
# nagios          ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/
#
# This lets the nagios user run all commands in that directory (and only them)
# without asking for a password.  If you do this, make sure you don't give
# random users write access to that directory or its contents!
# command_prefix=/usr/bin/sudo 
# DEBUGGING OPTION
# This option determines whether or not debugging messages are logged to the
# syslog facility.
# Values: 0=debugging off, 1=debugging on
#debug=0
debug=1
# COMMAND TIMEOUT
# This specifies the maximum number of seconds that the NRPE daemon will
# allow plugins to finish executing before killing them off.
command_timeout=60
# CONNECTION TIMEOUT
# This specifies the maximum number of seconds that the NRPE daemon will
# wait for a connection to be established before exiting. This is sometimes
# seen where a network problem stops the SSL being established even though
# all network sessions are connected. This causes the nrpe daemons to
# accumulate, eating system resources. Do not set this too low.
connection_timeout=300
# WEEK RANDOM SEED OPTION
# This directive allows you to use SSL even if your system does not have
# a /dev/random or /dev/urandom (on purpose or because the necessary patches
# were not applied). The random number generator will be seeded from a file
# which is either a file pointed to by the environment valiable $RANDFILE
# or $HOME/.rnd. If neither exists, the pseudo random number generator will
# be initialized and a warning will be issued.
# Values: 0=only seed from /dev/[u]random, 1=also seed from weak randomness
#allow_weak_random_seed=1
# INCLUDE CONFIG FILE
# This directive allows you to include definitions from an external config file.
#include=<somefile.cfg>
# INCLUDE CONFIG DIRECTORY
# This directive allows you to include definitions from config files (with a
# .cfg extension) in one or more directories (with recursion).
#include_dir=<somedirectory>
#include_dir=<someotherdirectory>
# COMMAND DEFINITIONS
# Command definitions that this daemon will run.  Definitions
# are in the following format:
#
# command[<command_name>]=<command_line>
#
# When the daemon receives a request to return the results of <command_name>
# it will execute the command specified by the <command_line> argument.
#
# Unlike Nagios, the command line cannot contain macros - it must be
# typed exactly as it should be executed.
#
# Note: Any plugins that are used in the command lines must reside
# on the machine that this daemon is running on!  The examples below
# assume that you have plugins installed in a /usr/local/nagios/libexec
# directory.  Also note that you will have to modify the definitions below
# to match the argument format the plugins expect.  Remember, these are
# examples only!
# The following examples use hardcoded command arguments...
command[check_users]=/usr/lib/nagios/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/check_load -w 3,3,3 -c 10,10,10
command[check_zombie_procs]=/usr/lib/nagios/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib/nagios/check_procs -w 150 -c 200 
command[check_disk]=/usr/lib/nagios/check_disk -w 20% -c 10% -p /dev/sda1 -p /dev/sda3
command[check_disk_sda]=/usr/lib/nagios/check_disk -w 20% -c 10% -p /dev/sda1 -p /dev/sda3
# The following examples allow user-supplied arguments and can
# only be used if the NRPE daemon was compiled with support for 
# command arguments *AND* the dont_blame_nrpe directive in this
# config file is set to '1'.  This poses a potential security risk, so
# make sure you read the SECURITY file before doing this.
#command[check_users]=/usr1/nagios/libexec/check_users -w $ARG1$ -c $ARG2$
#command[check_load]=/usr1/nagios/libexec/check_load -w $ARG1$ -c $ARG2$
#command[check_disk]=/usr1/nagios/libexec/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$
#command[check_procs]=/usr1/nagios/libexec/check_procs -w $ARG1$ -c $ARG2$ -s $ARG3$
#EOF

MartinEgli commented 7 years ago

As Code locks better!

hedenface commented 7 years ago

Ok - so let's start over then. For the simple fact that going up and reading everything over is leaving me rather confused. Answer these questions:

What is the server OS / arch / version that is running the NRPE/NSClient daemon?
What is the version of NRPE/NSClient daemon running?
What is the server OS / arch / version that is running check_nrpe?
What is the version of check_nrpe?

MartinEgli commented 7 years ago

Monitoring System Icinga2 on Raspberry PI3 Raspbian Stretch, check_nrpe 3.2.1. Firewall IPFire package: nagios_nrpe 2.12 i686 AMD G-T40E Processor AuthenticAMD GNU/Linux

ladinek commented 7 years ago

Windows 2008R2, nsclient 0.4.3.143 2015-04-29 Windows 2012R2 nsclient 0.4.4.15 2015-11-25 various versions of Windows (x64), nsclient 4.3-4.4, always the same

[/settings/NRPE/server] ssl options = verify mode = none insecure = true allow arguments = true allow nasty characters = true

answered in (1)
Linux raspberrypi 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l GNU/Linux
NRPE Plugin for Nagios Copyright (c) 1999-2008 Ethan Galstad (nagios@nagios.org) Version: 3.0.1 Last Modified: 09-08-2016 License: GPL v2 with exemptions (-l for more info) SSL/TLS Available: OpenSSL 0.9.6 or higher required

This 3.0.1 version got from package repository is the only one I got working with -2 –P 1024 options.

Tried also self-compiled 2.15 (does not have the –P option) – got these results::

root@raspberrypi:/home/pi/nrpe-2.15/src# ./check_nrpe -H 192.168.32.35 -n CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for error messages.

root@raspberrypi:/home/pi/nrpe-2.15/src# ./check_nrpe -H 192.168.32.35 CHECK_NRPE: Error - Could not complete SSL handshake.

and 3.2.1. With 3.2.1, I got this results:

root@raspberrypi:/home/pi/nrpe-master/src# ./check_nrpe -2 -P 1024 -H 192.168.32.35 CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with 192.168.32.35: 1

root@raspberrypi:/home/pi/nrpe-master/src# ./check_nrpe -2 -P 1024 -H 192.168.32.35 -n CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected).

From: Bryan Heden [mailto:notifications@github.com] Sent: Monday, November 20, 2017 3:44 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

Ok - so let's start over then. For the simple fact that going up and reading everything over is leaving me rather confused. Answer these questions:

What is the server OS / arch / version that is running the NRPE/NSClient daemon?
What is the version of NRPE/NSClient daemon running?
What is the server OS / arch / version that is running check_nrpe?
What is the version of check_nrpe?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345715937, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO22PH503kr2Ys4R3PdCrCjMcmw4Cks5s4ZA1gaJpZM4QLIx9.

hedenface commented 7 years ago

So, I just tested this with 2 different servers - one running windows with the version of nsclient I mentioned earlier, and one running Linux on x86_64 with NRPE 3.2.1 running as a daemon.

I then compiled NRPE 3.2.1 on my raspberry pi (uname -a : Linux raspberrypi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux) and ran check_nrpe. Here are the results, in order:

root@raspberrypi:/home/pi/nrpe-master/src# ./check_nrpe -H 192.168.3.15
I (0.4.4.23 2016-04-05) seem to be doing fine...

root@raspberrypi:/home/pi/nrpe-master/src# ./check_nrpe -H 192.168.6.251 -n
NRPE v3.2.1

MartinEgli commented 6 years ago

@hedenface Can you do it on a Raspberry with Raspbian Stretch?

ladinek commented 6 years ago

I installed fresh card with just bare Debian Stretch (debian stretch lite) on my Pi. Performed just apt-get update, apt-get upgrade and reboot.

Linux raspberrypi 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l GNU/Linux

Then installed nagios-nrpe-plugin from repository. It is 3.0.1 version.

Tried various combinations: pi@raspberrypi:/usr/lib/nagios/plugins $ ./check_nrpe -H 192.168.32.35 Error in `./check_nrpe': corrupted size vs. prev_size: 0x01e83168 Aborted pi@raspberrypi:/usr/lib/nagios/plugins $ ./check_nrpe -H 192.168.32.35 -n CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected). pi@raspberrypi:/usr/lib/nagios/plugins $ ./check_nrpe -2 -H 192.168.32.35 -n CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected). pi@raspberrypi:/usr/lib/nagios/plugins $ ./check_nrpe -2 -P 1024 -H 192.168.32.35 -n CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected). pi@raspberrypi:/usr/lib/nagios/plugins $ ./check_nrpe -2 -P 1024 -H 192.168.32.35 I (0.4.3.143 2015-04-29) seem to be doing fine...

On the nsclient++ side running in test mode, I got D:\source\nscp\include\socket/connection.hpp:243 D nrpe Accepting connection from: 192.168.32.192, count=1 E nrpe Failed to establish secure connection: unknown protocol: 252 D:\source\nscp\include\socket/connection.hpp:243 D nrpe Accepting connection from: 192.168.32.192, count=1

Please note the message „Failed to establish secure connection“ even when plugin executed with –n option.

Later, I will download and compile latest version of the plugin and let you know.

Regards,

Vladimir

From: Bryan Heden [mailto:notifications@github.com] Sent: Monday, November 20, 2017 9:38 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

So, I just tested this with 2 different servers - one running windows with the version of nsclient I mentioned earlier, and one running Linux on x86_64 with NRPE 3.2.1 running as a daemon.

I then compiled NRPE 3.2.1 on my raspberry pi (uname -a : Linux raspberrypi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux) and ran check_nrpe. Here are the results, in order:

root@raspberrypi:/home/pi/nrpe-master/src# ./check_nrpe -H 192.168.3.15

I (0.4.4.23 2016-04-05) seem to be doing fine...

root@raspberrypi:/home/pi/nrpe-master/src# ./check_nrpe -H 192.168.6.251 -n

NRPE v3.2.1

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345823821, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO0R36rfsGwwPXSQ9iO4Dfa_qmlSIks5s4eMXgaJpZM4QLIx9.

MartinEgli commented 6 years ago

Linux icinga 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l GNU/Linux PI NRPE Plugin for Nagios Version: 3.0.1 IPFIRE NRPE 2.12

root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.101.254
*** Error in `./check_nrpe': corrupted size vs. prev_size: 0x01fa0ad8 ***
Abgebrochen

root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.101.254 -n
CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected).

root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -2 -H 192.168.101.254 -n
CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected).

root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -2 -P 1024 -H 192.168.101.254 -n
CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected).

root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -2 -P 1024 -H 192.168.101.254
CHECK_NRPE: Response packet had invalid CRC32.

root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -2 -P 512 -H 192.168.101.254
CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected).

my results are diffrent. I have only -1 bytes resived. my "... - only -1 ..." and yours "... - only 0 ..."

IPFire log for root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -2 -P 1024 -H 192.168.101.254 CHECK_NRPE: Response packet had invalid CRC32.

Nov 21 11:44:38 ipfire01 nrpe[20394]: Connection from 192.168.101.10 port 21662
Nov 21 11:44:38 ipfire01 nrpe[20394]: Host address is in allowed_hosts
Nov 21 11:44:38 ipfire01 nrpe[20394]: Handling the connection...
Nov 21 11:44:38 ipfire01 nrpe[20394]: Host is asking for command '_NRPE_CHECK' to be run...
Nov 21 11:44:38 ipfire01 nrpe[20394]: Response: NRPE v2.12
Nov 21 11:44:38 ipfire01 nrpe[20394]: Return Code: 0, Output: NRPE v2.12
Nov 21 11:44:38 ipfire01 nrpe[20394]: Connection from 192.168.101.10 closed.

ladinek commented 6 years ago

I installed Debian Jessie, after usual apt-get update/upgrade (Linux raspberrypi 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux) i tried at first package nagios-nrpe-plugin, which is 2.15 version in the case of Jessie. pi@raspberrypi:/usr/lib/nagios/plugins $ ./check_nrpe -H 192.168.32.35 I (0.4.3.143 2015-04-29) seem to be doing fine... pi@raspberrypi:/usr/lib/nagios/plugins $ ./check_nrpe -H 192.168.32.35 -n CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for error messages.

Then I dowloaded and compiled latest 3.2.1 version ./configure --disable-ssl --enable-command-args

and got following results (same without -2 and –P 1024 options, same with ./configure without above options): pi@raspberrypi:~/nrpe-3.2.1 $ src/check_nrpe -2 -P 1024 -H 192.168.32.35 -n CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected). pi@raspberrypi:~/nrpe-3.2.1 $ src/check_nrpe -2 -P 1024 -H 192.168.32.35 CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected).

On the nsclient side, there is again protocol error:

E nrpe Failed to establish secure connection: unknown protocol: 252 D:\source\nscp\include\socket/connection.hpp:243

From: Bryan Heden [mailto:notifications@github.com] Sent: Monday, November 20, 2017 2:37 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

Are you able to compile from source on the ras to test? Ensure NSClient SSL is disabled, and then run ./configure with --disable-ssl and --enable-command-args.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345697380, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO54icf5stEF_uXFxUREh2azpl-2Zks5s4YCOgaJpZM4QLIx9.

hedenface commented 6 years ago

I think in both of your cases your configurations are probably messed up. I won't be spending any more time debugging this, as I don't actually think anything is broken. If you can find me something definitive, I'll reconsider.

ladinek commented 6 years ago

One more update, the server 192.168.32.35 has Windows Server 2008R2 (eng) and NSCLIENT 0.4.3.143, I tried also another one, pi@raspberrypi:/usr/lib/nagios/plugins $ ./check_nrpe -H 192.168.32.54 I (0.4.4.15 2015-11-25) seem to be doing fine... pi@raspberrypi:/usr/lib/nagios/plugins $ ./check_nrpe -H 192.168.32.54 -n CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for error messages.

and this server has Windows Server 2012R2 (eng) and NSCLIENT 4.4.15 version. But the behavior is exactly the same.

--------- previsous mail -------------------

I installed Debian Jessie, after usual apt-get update/upgrade (Linux raspberrypi 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux) i tried at first package nagios-nrpe-plugin, which is 2.15 version in the case of Jessie. pi@raspberrypi:/usr/lib/nagios/plugins $ ./check_nrpe -H 192.168.32.35 I (0.4.3.143 2015-04-29) seem to be doing fine... pi@raspberrypi:/usr/lib/nagios/plugins $ ./check_nrpe -H 192.168.32.35 -n CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for error messages.

Then I dowloaded and compiled latest 3.2.1 version ./configure --disable-ssl --enable-command-args

and got following results (same without -2 and –P 1024 options, same with ./configure without above options): pi@raspberrypi:~/nrpe-3.2.1 $ src/check_nrpe -2 -P 1024 -H 192.168.32.35 -n CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected). pi@raspberrypi:~/nrpe-3.2.1 $ src/check_nrpe -2 -P 1024 -H 192.168.32.35 CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected).

On the nsclient side, there is again protocol error:

E nrpe Failed to establish secure connection: unknown protocol: 252 D:\source\nscp\include\socket/connection.hpp:243

From: Bryan Heden [mailto:notifications@github.com] Sent: Monday, November 20, 2017 2:37 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

Are you able to compile from source on the ras to test? Ensure NSClient SSL is disabled, and then run ./configure with --disable-ssl and --enable-command-args.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-345697380, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO54icf5stEF_uXFxUREh2azpl-2Zks5s4YCOgaJpZM4QLIx9.

ladinek commented 6 years ago

But what can be messed up? Just to eliminate this, I created clean out-of-the box Raspberry OS, not configured anything – just installed repository package version of the check_nrpe, then downloaded and compiled latest 3.2.1 version. On the tested machine side, there is nsclient++ very simple plain configuration, working perfectly in many instances against any Intel (x64) based Nagios, being that Jessie or Stretch.

If I could help by running some debug version to find what is happening, I will make every effort to be helpful.

Vladimir

From: Bryan Heden [mailto:notifications@github.com] Sent: Tuesday, November 21, 2017 3:53 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

I think in both of your cases your configurations are probably messed up. I won't be spending any more time debugging this, as I don't actually think anything is broken. If you can find me something definitive, I'll reconsider.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-346050382, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwOwW3nV904wDv37mzR-q8GIihuwilks5s4uPJgaJpZM4QLIx9.

hedenface commented 6 years ago

But I also went through the entire process from scratch (fresh compiles) and had no issues. I'm not saying there isn't a bug, I'm just saying I haven't seen it (yet). You can turn debug logging on for NRPE and take a look at the output and see what's going on.

Maybe try upgrading NSClient to 0.4.4.x and see if that fixes it. For more of a troubleshooting situation like this one, I'm happy to help, but you're likely to get faster responses on the support forum: https://support.nagios.com/forum

MartinEgli commented 6 years ago

It is not only a problem with NSClient! I have the problem with the NRPE Server. Is it the same problem or not? How can I help you? why is there sometime no log on Server?

I made same test with 3.0.1 and 3.2.1.

Server check nrpe 3.0.1 and 3.2.1 OpenSSL 1.1.0f 25 May 2017

Client NRPE 2.12 OpenSSL 1.0.2m 2 Nov 2017

Version 3.0.1 Server

root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.101.254
*** Error in `./check_nrpe': corrupted size vs. prev_size: 0x00764ad8 ***
Abgebrochen

Nov 21 19:15:20 icinga check_nrpe: Remote 192.168.101.254 does not support Version 3 Packets

Client

Nov 21 19:15:11 ipfire01 nrpe[14750]: Connection from 192.168.101.10 port 235
Nov 21 19:15:11 ipfire01 nrpe[14750]: Host address is in allowed_hosts
Nov 21 19:15:11 ipfire01 nrpe[14750]: Handling the connection...
Nov 21 19:15:11 ipfire01 nrpe[14750]: Host is asking for command '_NRPE_CHECK' to be run...
Nov 21 19:15:11 ipfire01 nrpe[14750]: Response: NRPE v2.12
Nov 21 19:15:11 ipfire01 nrpe[14750]: Return Code: 0, Output: NRPE v2.12
Nov 21 19:15:11 ipfire01 nrpe[14750]: Connection from 192.168.101.10 closed.

Server

root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -2 -H 192.168.101.254
*** Error in `./check_nrpe': corrupted size vs. prev_size: 0x01d4d168 ***
Abgebrochen

No Logs

Client

Nov 21 19:16:32 ipfire01 nrpe[14924]: Connection from 192.168.101.10 port 3819
Nov 21 19:16:32 ipfire01 nrpe[14924]: Host address is in allowed_hosts
Nov 21 19:16:32 ipfire01 nrpe[14924]: Handling the connection...
Nov 21 19:16:32 ipfire01 nrpe[14924]: Host is asking for command '_NRPE_CHECK' to be run...
Nov 21 19:16:32 ipfire01 nrpe[14924]: Response: NRPE v2.12
Nov 21 19:16:32 ipfire01 nrpe[14924]: Return Code: 0, Output: NRPE v2.12
Nov 21 19:16:32 ipfire01 nrpe[14924]: Connection from 192.168.101.10 closed.

Server

root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -2 -P 1024 -H 192.168.101.254
CHECK_NRPE: Response packet had invalid CRC32.

Nov 21 19:18:26 icinga check_nrpe: Remote 192.168.101.254 accepted a Version 2 Packet

Client

Nov 21 19:18:16 ipfire01 nrpe[15173]: Connection from 192.168.101.10 port 8427
Nov 21 19:18:16 ipfire01 nrpe[15173]: Host address is in allowed_hosts
Nov 21 19:18:16 ipfire01 nrpe[15173]: Handling the connection...
Nov 21 19:18:16 ipfire01 nrpe[15173]: Host is asking for command '_NRPE_CHECK' to be run...
Nov 21 19:18:16 ipfire01 nrpe[15173]: Response: NRPE v2.12
Nov 21 19:18:16 ipfire01 nrpe[15173]: Return Code: 0, Output: NRPE v2.12
Nov 21 19:18:16 ipfire01 nrpe[15173]: Connection from 192.168.101.10 closed.

V 3.2.1 Server

root@icinga:/usr/local/nagios/libexec# ./check_nrpe -H 192.168.101.254          CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with 192.168.101.254: 1

Nov 21 19:20:01 icinga check_nrpe: Error: (!log_opts) Could not complete SSL handshake with 192.168.101.254: dh key too small

Client

Nov 21 19:19:51 ipfire01 nrpe[15398]: Connection from 192.168.101.10 port 14059
Nov 21 19:19:51 ipfire01 nrpe[15398]: Host address is in allowed_hosts
Nov 21 19:19:51 ipfire01 nrpe[15398]: Handling the connection...
Nov 21 19:19:51 ipfire01 nrpe[15398]: Error: Could not complete SSL handshake. 1 
Nov 21 19:19:51 ipfire01 nrpe[15398]: Connection from 192.168.101.10 closed.

Server

root@icinga:/usr/local/nagios/libexec# ./check_nrpe -2 -H 192.168.101.254       CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with 192.168.101.254: 1

Nov 21 19:22:11 icinga check_nrpe: Error: (!log_opts) Could not complete SSL handshake with 192.168.101.254: dh key too small

Client

Nov 21 19:22:02 ipfire01 nrpe[15778]: Connection from 192.168.101.10 port 21739
Nov 21 19:22:02 ipfire01 nrpe[15778]: Host address is in allowed_hosts
Nov 21 19:22:02 ipfire01 nrpe[15778]: Handling the connection...
Nov 21 19:22:02 ipfire01 nrpe[15778]: Error: Could not complete SSL handshake. 1 
Nov 21 19:22:02 ipfire01 nrpe[15778]: Connection from 192.168.101.10 closed.

Server

root@icinga:/usr/local/nagios/libexec# ./check_nrpe -2 -P 1024 -H 192.168.101.254
CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with 192.168.101.254: 1

Nov 21 19:23:15 icinga check_nrpe: Error: (!log_opts) Could not complete SSL handshake with 192.168.101.254: dh key too small

Client

Nov 21 19:23:06 ipfire01 nrpe[15933]: Connection from 192.168.101.10 port 27371
Nov 21 19:23:06 ipfire01 nrpe[15933]: Host address is in allowed_hosts
Nov 21 19:23:06 ipfire01 nrpe[15933]: Handling the connection...
Nov 21 19:23:06 ipfire01 nrpe[15933]: Error: Could not complete SSL handshake. 1 
Nov 21 19:23:06 ipfire01 nrpe[15933]: Connection from 192.168.101.10 closed.

Server

root@icinga:/usr/local/nagios/libexec# ./check_nrpe -2 -P 1024 -H 192.168.101.254 -n
CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected).

no log

Client

Nov 21 19:24:17 ipfire01 nrpe[16109]: Connection from 192.168.101.10 port 31467
Nov 21 19:24:17 ipfire01 nrpe[16109]: Host address is in allowed_hosts
Nov 21 19:24:17 ipfire01 nrpe[16109]: Handling the connection...
Nov 21 19:24:17 ipfire01 nrpe[16109]: Error: Could not complete SSL handshake. 1 
Nov 21 19:24:17 ipfire01 nrpe[16109]: Connection from 192.168.101.10 closed.

ladinek commented 6 years ago

It is absolutely clear that problem is in the Raspberry Pi version of check_nrpe. I don´t understand how it is possible that it works to Bryan. I tried two different Raspberries (in fact one 2B and one 3B), different SD/USB boots, jessie, Stretch, repo-package, own compiling, always the same results. Same version of Intel x64 debian against my NSclients (without any change on their side except IP address allowed) works.

From: MartinEgli [mailto:notifications@github.com] Sent: Tuesday, November 21, 2017 8:04 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Author Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

It is not only a problem with NSClient! I have the problem with the NRPE Server. Is it the same problem or not? How can I help you? why is there sometime no log on Server?

I made same test with 3.0.1 and 3.2.1.

Server check nrpe 3.0.1 and 3.2.1 OpenSSL 1.1.0f 25 May 2017

Client NRPE 2.12 OpenSSL 1.0.2m 2 Nov 2017

Version 3.0.1 Server

root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.101.254

Error in `./check_nrpe': corrupted size vs. prev_size: 0x00764ad8

Abgebrochen

Nov 21 19:15:20 icinga check_nrpe: Remote 192.168.101.254 does not support Version 3 Packets

Client

Nov 21 19:15:11 ipfire01 nrpe[14750]: Connection from 192.168.101.10 port 235

Nov 21 19:15:11 ipfire01 nrpe[14750]: Host address is in allowed_hosts

Nov 21 19:15:11 ipfire01 nrpe[14750]: Handling the connection...

Nov 21 19:15:11 ipfire01 nrpe[14750]: Host is asking for command '_NRPE_CHECK' to be run...

Nov 21 19:15:11 ipfire01 nrpe[14750]: Response: NRPE v2.12

Nov 21 19:15:11 ipfire01 nrpe[14750]: Return Code: 0, Output: NRPE v2.12

Nov 21 19:15:11 ipfire01 nrpe[14750]: Connection from 192.168.101.10 closed.

Server

root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -2 -H 192.168.101.254

Error in `./check_nrpe': corrupted size vs. prev_size: 0x01d4d168

Abgebrochen

No Logs

Client

Nov 21 19:16:32 ipfire01 nrpe[14924]: Connection from 192.168.101.10 port 3819

Nov 21 19:16:32 ipfire01 nrpe[14924]: Host address is in allowed_hosts

Nov 21 19:16:32 ipfire01 nrpe[14924]: Handling the connection...

Nov 21 19:16:32 ipfire01 nrpe[14924]: Host is asking for command '_NRPE_CHECK' to be run...

Nov 21 19:16:32 ipfire01 nrpe[14924]: Response: NRPE v2.12

Nov 21 19:16:32 ipfire01 nrpe[14924]: Return Code: 0, Output: NRPE v2.12

Nov 21 19:16:32 ipfire01 nrpe[14924]: Connection from 192.168.101.10 closed.

Server

root@icinga:/usr/lib/nagios/plugins# ./check_nrpe -2 -P 1024 -H 192.168.101.254

CHECK_NRPE: Response packet had invalid CRC32.

Nov 21 19:18:26 icinga check_nrpe: Remote 192.168.101.254 accepted a Version 2 Packet

Client

Nov 21 19:18:16 ipfire01 nrpe[15173]: Connection from 192.168.101.10 port 8427

Nov 21 19:18:16 ipfire01 nrpe[15173]: Host address is in allowed_hosts

Nov 21 19:18:16 ipfire01 nrpe[15173]: Handling the connection...

Nov 21 19:18:16 ipfire01 nrpe[15173]: Host is asking for command '_NRPE_CHECK' to be run...

Nov 21 19:18:16 ipfire01 nrpe[15173]: Response: NRPE v2.12

Nov 21 19:18:16 ipfire01 nrpe[15173]: Return Code: 0, Output: NRPE v2.12

Nov 21 19:18:16 ipfire01 nrpe[15173]: Connection from 192.168.101.10 closed.

V 3.2.1 Server

root@icinga:/usr/local/nagios/libexec# ./check_nrpe -H 192.168.101.254 CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with 192.168.101.254: 1

Nov 21 19:20:01 icinga check_nrpe: Error: (!log_opts) Could not complete SSL handshake with 192.168.101.254: dh key too small

Client

Nov 21 19:19:51 ipfire01 nrpe[15398]: Connection from 192.168.101.10 port 14059

Nov 21 19:19:51 ipfire01 nrpe[15398]: Host address is in allowed_hosts

Nov 21 19:19:51 ipfire01 nrpe[15398]: Handling the connection...

Nov 21 19:19:51 ipfire01 nrpe[15398]: Error: Could not complete SSL handshake. 1

Nov 21 19:19:51 ipfire01 nrpe[15398]: Connection from 192.168.101.10 closed.

Server

root@icinga:/usr/local/nagios/libexec# ./check_nrpe -2 -H 192.168.101.254 CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with 192.168.101.254: 1

Nov 21 19:22:11 icinga check_nrpe: Error: (!log_opts) Could not complete SSL handshake with 192.168.101.254: dh key too small

Client

Nov 21 19:22:02 ipfire01 nrpe[15778]: Connection from 192.168.101.10 port 21739

Nov 21 19:22:02 ipfire01 nrpe[15778]: Host address is in allowed_hosts

Nov 21 19:22:02 ipfire01 nrpe[15778]: Handling the connection...

Nov 21 19:22:02 ipfire01 nrpe[15778]: Error: Could not complete SSL handshake. 1

Nov 21 19:22:02 ipfire01 nrpe[15778]: Connection from 192.168.101.10 closed.

Server

root@icinga:/usr/local/nagios/libexec# ./check_nrpe -2 -P 1024 -H 192.168.101.254

CHECK_NRPE: (ssl_err != 5) Error - Could not complete SSL handshake with 192.168.101.254: 1

Nov 21 19:23:15 icinga check_nrpe: Error: (!log_opts) Could not complete SSL handshake with 192.168.101.254: dh key too small

Client

Nov 21 19:23:06 ipfire01 nrpe[15933]: Connection from 192.168.101.10 port 27371

Nov 21 19:23:06 ipfire01 nrpe[15933]: Host address is in allowed_hosts

Nov 21 19:23:06 ipfire01 nrpe[15933]: Handling the connection...

Nov 21 19:23:06 ipfire01 nrpe[15933]: Error: Could not complete SSL handshake. 1

Nov 21 19:23:06 ipfire01 nrpe[15933]: Connection from 192.168.101.10 closed.

Server

root@icinga:/usr/local/nagios/libexec# ./check_nrpe -2 -P 1024 -H 192.168.101.254 -n

CHECK_NRPE: Receive header underflow - only -1 bytes received (4 expected).

no log

Client

Nov 21 19:24:17 ipfire01 nrpe[16109]: Connection from 192.168.101.10 port 31467

Nov 21 19:24:17 ipfire01 nrpe[16109]: Host address is in allowed_hosts

Nov 21 19:24:17 ipfire01 nrpe[16109]: Handling the connection...

Nov 21 19:24:17 ipfire01 nrpe[16109]: Error: Could not complete SSL handshake. 1

Nov 21 19:24:17 ipfire01 nrpe[16109]: Connection from 192.168.101.10 closed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-346128020, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO7i1AM4r9FjYj-I1SScyBoZPj862ks5s4x6IgaJpZM4QLIx9.

hedenface commented 6 years ago

It is absolutely clear that problem is in the Raspberry Pi version of check_nrpe.

This isn't absolutely clear - that is the problem.

I don´t understand how it is possible that it works to Bryan.

I don't either but it does.

So, I will say that the differing OpenSSL versions could potentially have something to do with it. Downgrade the newer one to openssl 1.0.x and see what happens. I had a lot of issues during testing, and thought I had them all worked out. To be fair, when I did my quick test here on my end I was using 1.1.x on one and 1.0.x on the other - so I doubt that's it.

Same version of Intel x64 debian against my NSclients (without any change on their side except IP address allowed) works.

@ladinek Did you upgrade NSClient to 0.4.4.x?

ladinek commented 6 years ago

Yes, in my recent mailing I tried also against Win2012R2 with NSclient 4.4.15. Openssl... however, how can you explain, that problems are with encryption OFF (either compiling –no-ssl or –n switch)? I looked into 3.2.1 source and there is a lot of potential debugging, however I don´t know how to enable maximum debugging – I don´t use NRPE Daemon, even when I had nrpe.cfg only one line debug=1, check_nrpe respoded that there is too many parameters in nrpe.cfg. I found the –g option for log file (in the syslog there is lot of another items, so havine separate log file is definitely better), but not how to elevate debugging info.

From: Bryan Heden [mailto:notifications@github.com] Sent: Tuesday, November 21, 2017 8:40 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Mention Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

It is absolutely clear that problem is in the Raspberry Pi version of check_nrpe. This isn't absolutely clear - that is the problem.

I don´t understand how it is possible that it works to Bryan. I don't either but it does.

So, I will say that the differing OpenSSL versions could potentially have something to do with it. Downgrade the newer one to openssl 1.0.x and see what happens. I had a lot of issues during testing, and thought I had them all worked out. To be fair, when I did my quick test here on my end I was using 1.1.x on one and 1.0.x on the other - so I doubt that's it.

Same version of Intel x64 debian against my NSclients (without any change on their side except IP address allowed) works. @ladinekhttps://github.com/ladinek Did you upgrade NSClient to 0.4.4.x?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-346138166, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwO9PDjOiX3pQTxp1ZMXWxZhcPbGTQks5s4yb2gaJpZM4QLIx9.

hedenface commented 6 years ago

Openssl... however, how can you explain, that problems are with encryption OFF (either compiling –no-ssl or –n switch)?

This is the problem with two people posting what appears to be unrelated issues in the same thread.

Listen, I just tested having nrpe daemon running a pi with 2.15 and then checked it via check_nrpe with 3.2.1 and I had absolutely no issue.

@ladinek Please show me your ENTIRE nsclient.ini - not just the parts you think are relevant. I notice your NRPE server doesn't have a port specified from the section you listed earlier.

MartinEgli commented 6 years ago

We use same os on a Raspi with the same check_nrpe. Same problem or not?

MartinEgli commented 6 years ago

What is a good name for my issue?

MartinEgli commented 6 years ago

Why is there no -v for verbose?

http://nagios-plugins.org/doc/guidelines.html

ladinek commented 6 years ago

I recompiled 3.2.1 with lots of debugging prints, and what I found is that we never receive any data on the Raspberry client. It first tries v3 – returned 0, to check_nrpe falls back to v2, tries another attempt, again receive 0, and respond with message about underflow. On the nsclient++ side in test mode, there is following message: D nrpe Accepting connection from: 192.168.32.197, count=1 E nrpe Failed to establish secure connection: unknown protocol: 252 c:\source\nscp\include\socket/connection.hpp:243

Same error appears even in the case I add –n switch to invocation, so I think the request packet is somehow malformed. What about little endian-big endian? Bryan said he tried check_nrpe on Raspberry against nrpe daemon on another Raspberry, so the error can cancel itself? It is only my theory, but what else can make those issues?

From: Bryan Heden [mailto:notifications@github.com] Sent: Tuesday, November 21, 2017 9:13 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Mention Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

Openssl... however, how can you explain, that problems are with encryption OFF (either compiling –no-ssl or –n switch)?

This is the problem with two people posting what appears to be unrelated issues in the same thread.

Listen, I just tested having nrpe daemon running a pi with 2.15 and then checked it via check_nrpe with 3.2.1 and I had absolutely no issue.

@ladinekhttps://github.com/ladinek Please show me your ENTIRE nsclient.ini - not just the parts you think are relevant. I notice your NRPE server doesn't have a port specified from the section you listed earlier.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-346146978, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwOzYI4XXe4LfRDCd02z-o2T4H6Klcks5s4y6ugaJpZM4QLIx9.

ladinek commented 6 years ago

I found workaround for check_nrpe 3.2.1 against nsclient both 4.3 and 4.4 versions. I have compiled check_nrpe with --disable-ssl --enable-command-args configuration options. But either with or without –n option, on the nsclient side I always received E nrpe Failed to establish secure connection: unknown protocol: 252 D:\source\nscp\include\socket/connection.hpp:243 even when it should not use (-n) any encryption.

And check_nrpe ended with infamous CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected).

It seems to help adding [/settings/NRPE/server] use ssl = false

helps on both 4.3 and 4.4 versions.

From: Bryan Heden [mailto:notifications@github.com] Sent: Tuesday, November 21, 2017 9:13 PM To: NagiosEnterprises/nrpe Cc: Lízal Vladimír; Mention Subject: Re: [NagiosEnterprises/nrpe] check_nrpe not working on Raspberry PI (#173)

Openssl... however, how can you explain, that problems are with encryption OFF (either compiling –no-ssl or –n switch)?

This is the problem with two people posting what appears to be unrelated issues in the same thread.

Listen, I just tested having nrpe daemon running a pi with 2.15 and then checked it via check_nrpe with 3.2.1 and I had absolutely no issue.

@ladinekhttps://github.com/ladinek Please show me your ENTIRE nsclient.ini - not just the parts you think are relevant. I notice your NRPE server doesn't have a port specified from the section you listed earlier.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/NagiosEnterprises/nrpe/issues/173#issuecomment-346146978, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AETwOzYI4XXe4LfRDCd02z-o2T4H6Klcks5s4y6ugaJpZM4QLIx9.

hedenface commented 6 years ago

Bryan said he tried check_nrpe on Raspberry against nrpe daemon on another Raspberry, so the error can cancel itself? It is only my theory, but what else can make those issues?

I also tried it from a raspberry to a windows machine and a different linux machine.

I'm still waiting on your nsclient.ini file.

hedenface commented 6 years ago

We use same os on a Raspi with the same check_nrpe. Same problem or not?

With totally different servers running completely different nrpe server software.

Why is there no -v for verbose?

I don't know, that is a very good question. Either you can start a new issue requesting that functionality, or I'll create one. Best if you do it so you get the credit!

@ladinek I didn't see that you solved your issue before my last comment.

@MartinEgli :

check nrpe 3.0.1 and 3.2.1 OpenSSL 1.1.0f 25 May 2017 Client NRPE 2.12 OpenSSL 1.0.2m 2 Nov 2017

Your problem may very well be related to a lot of the OpenSSL stuff that was fixed in 3.2.0 and 3.2.1. OpenSSL itself marked a few of the methods we use for anonymous ssl as insecure in 1.1.x, so we had to force their usage when invoking. If you downgrade your openssl 1.1.x to 1.0.x and then recompile nrpe does that work?

MartinEgli commented 6 years ago

a ssl library is used when set ./configure --disable-ssl --enable-command-args or use the paremeter -n?

Current Raspbian is with OpenSSL 1.1.0f, I down't know the dependencies of other programms. I'll test it on a new installation.

NagiosEnterprises / nrpe

check_nrpe not working on Raspberry PI #173

General Options:

If you want to fill this file with all avalible options run the following command:

nscp settings --generate --add-defaults --load-all

If you want to activate a module and bring in all its options use:

nscp settings --activate-module --add-defaults

For details run: nscp settings --help