I have nagios client which gave sudden error after an upgrade. I reinstalled nagios-plugin and nrpe agent again but unable solve error. This version uses nrpe under xinetd.

# /usr/local/nagios/libexec/check_nrpe -H localhost
CHECK_NRPE: Error - Could not complete SSL handshake.

# netstat -plan | grep :5666
tcp        0      0 :::5666                     :::*                        LISTEN      20265/xinetd


# cat /etc/xinetd.d/nrpe | grep -i only_from
        only_from       =

# cat /etc/xinetd.d/nrpe
# default: on
# description: NRPE (Nagios Remote Plugin Executor)
service nrpe
        flags           = REUSE
        socket_type     = stream
        port            = 5666
        wait            = no
        user            = nagios
        group           = nagios
        server          = /usr/local/nagios/bin/nrpe
        server_args     = -c /usr/local/nagios/etc/nrpe.cfg --inetd
        log_on_failure  += USERID
        disable         = no
        only_from       =

Unable to telnet from client to server

# telnet 5666
Connected to
Escape character is '^]'.
Connection closed by foreign host.
  • no, I am trying this on client. – Mongrel Mar 8 '16 at 17:00
  • I have done that but still not getting the same error. – Mongrel Mar 8 '16 at 17:04
  • But If I am using xinetd instead of nrpe then its not necessary to add server IP in nrpe.cfg – Mongrel Mar 8 '16 at 17:10
  • Check your firewall block port 5666 or not – cuonglm Mar 8 '16 at 17:17
  • There is no firewall to block, but it should work on local local is also not working – Mongrel Mar 8 '16 at 17:18

NRPE hasn't been updated in a few years (September 2013), this is what it does on the server side

SSL_CTX_set_options(ctx,SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);

and the client (check_nrpe on Nagios server)

SSL_CTX_set_options(ctx,SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);

The SSLv23_xxx functions used to be the most compatible way to connect to any SSLv2 or SSLv3.x system. Both of the above are deprecated. While the code disables protocol versions 2.0 and 3.0 (leaving only TLS), the client connection will start with an SSLv2 ClientHello.

DH primes smaller than 1024 are now deemed insecure (though it might be 768 in some versions of OpenSSL). This explains why you cannot connect to yourself, the OpenSSL client (check_nrpe) will reject a short DH key. (ADH is used since it does not need a certificate and is hence "anonymous", not a good plan in an untrusted network but acceptable for this this purpose.)

I suspect you may also be running into a second problem connecting to the new system. What has probably happened is that the client (NSCA server) has updated to using a recent OpenSSL, SSLv2 has recently been disabled by default, though some distros have been doing that for years. In most cases there should still be an overlap in protocol/ciphersuite but it's possible and common for the TLS server (nrpe daemon in this case) with SSLv2 disabled to reject an SSLv2 ClientHello handshake packet, even though the client indicates SSLv3 or higher within the handshake (technical details here: https://security.stackexchange.com/questions/59367/what-exactly-determines-what-version-of-ssl-tls-is-used-when-accessing-a-site)

To fix this you may need to downgrade the OpenSSL on the updated system, or install a parallel older OpenSSL version which does not have these (sensible!) precautions. Neither sound like good options...

If you built nrpe yourself, should be suffient you will need to replace the call to get_dh512() with get_dh1024() and recompile it with a new static 1024-bit key -- to do this you will need to create a new 1024-bit prime by either modifying the hard-coded 512 in configure (line 6748) and rerunning it, or using

opensl dhparam -C 1024 | awk '/^-----/{exit} {print}' > include/dh.h

and then make to rebuild. You will probably also need to replace the call to SSLv23_client_method() with TLSv1_client_method() also so that an SSLv2 "compatible" ClientHello is not attempted and recompile check_nrpe on the Nagios server. Since you run the risk of breaking connectivity to other clients then you might need a second check_nrpe_new binary for "upgraded" servers, and use this in command/check_command of your templates (I don't think this should happen though).

(As a last resort you may be able to do something unpretty with socat or stunnel to bridge any mismatching, here's one way to do that: https://security.stackexchange.com/a/108850/18555 .)

A more precise answer will require the OpenSSL version (openssl version -a, or the relevant package manager output) and your distribution versions.

  • He is also doing the telnet wrong; he cannot telnet from the client to the nagios server nrpe port as only the nagios IP and localhost are accepted. – Rui F Ribeiro Mar 8 '16 at 20:36
  • @Mr.Spuratic This the only system which is giving error, other system which is updated are not having any issues. I will try to downgrade the openssl version on the upgraded system and check if I overcome the error. – Mongrel Mar 9 '16 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.