Check_nrpe: Error Could Not Complete Ssl Handshake.

22.09.2019
55 Comments

ここ最近、nagiosから飛んでくるエラー CHECKNRPE: Error - Could not complete SSL handshake.の原因を調査してた。ただ「繋がる時もある. Apr 3, 2019 - -vps nrpe44597: Error: (!logopts) Could not complete SSL handshake with x.x.x.x. I tried to follow this document NRPE - CHECKNRPE:.

Compiling or installing a distributed package won't make any difference with this issue. I'm suffering with this issue also on a Debian 8 system upgraded to Debian 9, however even after compiling the latest 'maint' branch, I'm still seeing it.I checkout out the git repo, checked out the 'maint' branch and ran:./configuremake allHave I missed a step? Wrote:When trying to apply on 3.0.1 as bundled in Stretch I found the that the package doesn't depend on openssl 1.1.x:NRPE 3.0.1 fails to build with OpenSSL 1.1.0 in stretch, the support for OpenSSL 1.1.0 was added in NRPE 3.1.x, which is now available in stretch-backports.Both the NRPE 3.0.x & 3.1.x packages have the issue that setting needdh to no, either with the reproducible build patch or the -with-need-dh configure option, also disables the USESSLDH definition.

Solaris

This is a bug in the package that was not spotted before, thanks for sharing your findings!I've updated the Debian package to address this issue in the following revision:. 3.2.0-2 (unstable). 3.1.1-1bpo9+2 (stretch-backports). 3.0.1-3+deb9u1 (stretch)The updates for unstable & stretch-backports have been uploaded and will be available on the mirrors in a few hours., can you build the proposed update for stretch and confirm that also fixes the issue for you?The sources are available in the stretch branch of the package git repository. After getting the new nrpe package from backports the issues still remain for me (running without a certificate) like a lot of people (will move to certificate validation soon). The allowed host is still running Debian Jessie (due to these issues on Stretch).Jul 6 15:41:11 hostname nrpe14160: CONNCHECKPEER: is this a blessed machine: x.x.x.x port 10971Jul 6 15:41:11 hostname nrpe14160: Connection from x.x.x.x port 10971Jul 6 15:41:11 hostname nrpe14160: isanallowedhost (AFINET): is host x.x.x.xx.x.x.x. If you enable ssllogging you'll probably see the following in /var/log/syslog: nrpe4634: Error: Could not complete SSL handshake with: no shared ciphernrpe4634: Error: This could be because you have not specified certificate or ca-certificate filesThis is related to the @SECLEVEL=0 changes from NRPE 3.2.0, you need to modify the /etc/nagios/nrpe.cfg to include (this is the new default in NRPE 3.2.0): sslcipherlist=ALL:!MD5:@STRENGTH:@SECLEVEL=0After restarting the nagios-nrpe-server service you should be able to use checknrpe = 3.1.1.

Nrpe4686: Connection from port 34692nrpe4686: Remote - SSL Version: TLSv1.2nrpe4686: Remote - TLSv1.2, Cipher is ADH-AES256-GCM-SHA384nrpe4686: SSL Not asking for client certificationnagios-nrpe (3.1.1-1bpo9+3) has been uploaded to stretch-backports which sets the sslcipherlist, this change is only required for NRPE 3.1.x built with OpenSSL 1.1.0. You can upgrade your Debian machines to stretch, but you'll need to disable SSL until the proposed-update is available. I've done this for all my private systems and at $DAYJOB.I've finished testing the proposed-update to confirm that SSL support (without certificates configured) between NRPE 2.x (2.15 on Debian jessie) and NRPE 3.x (3.0.1 & 3.1.1 on Debian stretch and 3.2.0 on Debian unstable) works as expected again.has been filed to request permission from the Debian stable Release Manager to upload the proposed-update. /etc/default/nagios-nrpe-server is a conffile managed by dpkg, after distribution upgrades you need to merge changes from the new configuration files into your own if you had modified the files (otherwise dpkg will install the new version). The following lists all the conffile that you need to inspect after an upgrade: find /etc -name '.dpkg-.'

find /etc -name '.ucf-.' Files with the.dpkg-new/.ucf-new &.dpkg-dist/.ucf-dist extension are for the new version in the upgraded package, files with the.dpkg-old/.ucf-old &.dpkg-remove/.ucf-remove are the old configuration files that can generally be removed.RedHat/Fedora/CentOS work similiarly with upgrades where the files use the.rpmnew extension.

It's the responsibility of the system administrator to merge the changes from the new configuration files and to preserve customizations.

If your Nagios status website shows the following error: CHECKNRPE: Error - Could not complete SSL handshake.The following could be the root cause:1.) It could be, that the NSCP client is not configured correctly. You can check the default configuration and check it again after that.As written, it is requited for some NSCP Clients to have the following entry in the nsclient.ini: /settings/NRPE/serverinsecure = true2.) The nagios server isn´t in the allowed hosts list.

So change the nsclient.ini on the affected server and add the IP address from the nagios server to the following section: /settings/default; ALLOWED HOSTS - A comaseparated list of allowed hosts. You can use netmasks (/ syntax) or. to create ranges.allowed hosts = 10.10.10.1. 2019 (2). May (1).

February (1). 2018 (19). December (1). July (3). June (3).

May (5). April (1). February (4).

January (2). 2017 (43). December (3). November (1). October (1).

Check_nrpe Error - Could Not Complete Ssl Handshake Windows Client

September (2). August (3). July (5). June (5).

May (5). April (4). March (7). February (4). January (3). 2016 (86).

December (10). November (8). October (9). September (14). August (7). July (12).

Handshake.Check_nrpe: Error Could Not Complete Ssl Handshake.

June (8). May (10). April (3).

Check_nrpe Error - Could Not Complete Ssl Handshake. Centos

March (5).