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 localhostCHECK_NRPE: Error - Could not complete SSL handshake.# netstat -plan | grep :5666tcp        0      0 :::5666                     :::*                        LISTEN      20265/xinetdunable to troubleshoot, need serious help. ThanksNagios-server-IP 10.10.3.30# cat /etc/xinetd.d/nrpe | grep -i only_from        only_from       = 127.0.0.1 10.10.3.30# 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       = 127.0.0.1 10.10.3.30}Unable to telnet from client to server# telnet 10.10.3.30 5666Trying 10.10.3.30...Connected to 10.10.3.30.Escape character is '^]'.Connection closed by foreign host.
nagios SSL handshake
linux;monitoring;nagios
NRPE hasn't been updated in a few years (September 2013), this is what it does on the server sideSSL_library_init();SSLeay_add_ssl_algorithms();meth=SSLv23_server_method();...SSL_CTX_set_options(ctx,SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);...SL_CTX_set_cipher_list(ctx,ADH);dh=get_dh512();and the client (check_nrpe on Nagios server) SSL_library_init();SSLeay_add_ssl_algorithms();meth=SSLv23_client_method();...SSL_CTX_set_options(ctx,SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);...SSL_CTX_set_cipher_list(ctx,ADH);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 usingopensl dhparam -C 1024 | awk '/^-----/{exit} {print}' > include/dh.hand 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.