CHECK_NRPE: Errore - Impossibile completare l'handshake SSL

Question

Ho un processo daemon NRPE in esecuzione su xinetd su istanza di Amazon ec2 e server nagios sulla mia macchina locale.

Il check_nrpe -H [amazon public IP] dà questo errore:

CHECK_NRPE: Error - Could not complete SSL handshake. 

Entrambi NRPE sono le stesse versioni. Entrambi sono compilati con questa opzione:

./configure --with-ssl=/usr/bin/openssl --with-ssl-lib=/usr/lib/i386-linux-gnu/ 

la voce "consentito host" contiene il mio indirizzo IP locale.

Quale potrebbe essere il possibile motivo di questo errore ora ??

Answer 1

Per verificare se è possibile accedervi, tentare un semplice telnet all'indirizzo: port, un ping o traceroute per vedere dove si sta bloccando.

telnet IP port 
ping IP 
traceroute -p $port IP 

Controllare inoltre sul server di destinazione che il daemon nrpe funzioni correttamente.

netstat -at | grep nrpe 

È inoltre necessario controllare le versioni di OpenSSL installate su entrambi i server, come ho visto questa pausa controlli occasione con l'handshake SSL!

Answer 2

Questo è un messaggio di errore di tipo catch-all per NRPE. Controlla le regole del tuo firewall e assicurati che la porta sia aperta. Prova anche a disabilitare SELinux e vedere se lascia passare la connessione. Probabilmente non è un problema SSL, ma solo un problema con la connessione rifiutata.

Answer 3

Se si esegue nrpe come un servizio, assicurarsi di avere questa linea nel vostro nrpe.cfg sul lato client:

# example 192. IP, yours will probably differ 
allowed_hosts=127.0.0.1,192.168.1.100 

Tu dici che è fatto, tuttavia, se si esegue sotto nrpe xinetd, assicurati di modificare la direttiva only_from nel file /etc/xinetd.d/nrpe.

Non dimenticare di riavviare il servizio xinetd:

service xinetd restart 

Answer 4

controllare il vostro /var/sys/system.log. Nel mio caso, si è scoperto che il mio IP monitorato era impostato su qualcosa di diverso da quello che ho impostato nel file nrpe.cfg. Non conosco la causa di questo cambiamento, però.

Answer 5

@jgritty aveva ragione. si dovrebbe modificare nrpe.cfg e nrpe file di configurazione per consentire l'accesso del server Nagios maestro:

vim /usr/local/nagios/etc/nrpe.cf 
allowed_hosts=127.0.0.1,172.16.16.150 

e

vim /etc/xinetd.d/nrpe 
only_from= 127.0.0.1 172.16.16.150 

Answer 6

Sembra che si esegue il server di Nagios in una macchina virtuale in un host-only Rete. Se è così, questo fermerebbe qualsiasi accesso esterno. Assicurarsi di disporre di una rete NAT o Bridged disponibile.

Answer 7

Assicurarsi di aver riavviato anche il Nagios Client Plugin.

Answer 8

Sto eseguendo nrpe utilizzando il servizio xinetd.

Assicurarsi anche (oltre ai passaggi di base di cui sopra) che l'utente nagios è l'autenticazione correttamente. Nel mio caso:

Jun 6 15:05:52 gse2 xinetd[33237]: **Unknown user: nagios**<br>[file=/etc/xinetd.d/nrpe] [line=9] 
Jun 6 15:05:52 gse2 xinetd[33237]: Error parsing attribute user - DISABLING 
SERVICE [file=/etc/xinetd.d/nrpe] [line=9] 
Jun 6 15:05:52 gse2 xinetd[33237]: **Unknown group: nagios**<br>[file=/etc/xinetd.d/nrpe] [line=10] 
Jun 6 15:05:52 gse2 xinetd[33237]: Error parsing attribute group - DISABLING 
SERVICE [file=/etc/xinetd.d/nrpe] [line=10] 
Jun 6 15:05:52 gse2 xinetd[33237]: Service nrpe missing attribute user - DISABLING 

Era visualizzato nei messaggi/var/log.
All'inizio mi è sfuggito, ma poi ho controllato il servizio ypbind e ho scoperto che non era stato avviato.
Dopo aver avviato ypbind, l'utente e il gruppo nagios si stavano autenticando correttamente, l'errore è andato via.

Answer 9

alcuni casi limite che si riavviano nagios-nrpe-server non sono utili, poiché il processo non è stato eliminato o non è stato riavviato correttamente.

basta ucciderlo manualmente quindi e iniziare.

Answer 10

errore handshake SSL msg.Beside l'allow_host si dovrebbe assegnare.

il server Nagios è in una LAN locale di tipo C indirizzo IP, ad esempio 192.168.xxxx

quando il bersaglio monitorato retroazione server msg SSL per il server Nagios locale, il messaggio dovrebbe prima viene al vostro IP del pubblico della tua linea, il messaggio non può attraversare l'IP pubblico nel tuo server nagios quale IP è interno.

è necessario NAT per guidare il messaggio SSL da server di destinazione al server Nagios interiore.

Oppure è un uso migliore "get" metodo che appena arrivato un messaggio monitor dal lato client Nagios, come ad esempio SNMP per soddisfare il monitor remoto di risorsa locale di server Linux.

SSL ha bisogno di feedback in doppia direzione.

migliori saluti

Answer 11

Per me impostando la seguente in /etc/nagios/nrpe.cfg il client lavorato:

dont_blame_nrpe=1 

E 'e Ubuntu 16.04 macchina. Per altri possibili problemi, consiglio di consultare i registri nrpe. Ecco un buon articolo per la configurazione dei registri.

Answer 12

Se si utilizza Debian 9, esiste il problema a known issue relativo a questo problema, causato dal supporto di rilascio OpenSSL per il metodo utilizzato da NRPE per l'avvio di connessioni SSL anonime.

La questione seems to be fixed, ma la correzione non ha fatto nei pacchetti ufficiali, ancora.

Attualmente sembra che non ci sia un work-around sicuro.