Nach dem Upgrade von Ubuntu 16.04 auf Ubuntu 18.04 hatte ich mit diversen Fehlern unter Nagios zu kämpfen. Die meisten waren im Zusammenhang mit SSL.
NRPE und NSClient++
Der NSClient++ bringt leider nur 512bit-DH-Schlüssel mit. Der aktuelle NRPE verlangt aber eine stärkere Verschlüsselung. Die Fehlermeldung die ich in Nagios erhalten habe war:
Error: Could not complete SSL handshake. <host> 1
Im nsclient.log war diese Fehlermeldung zu finden:
ssl alert handshake failure: 1040
Meine Lösung (nach einiger Recherchearbeit) ist:
Mit OpenSSL stärkere Diffie-Hellman-Schlüssel zu erzeugen und diese dann in die Clients zu verteilen (Fleißarbeit). Dazu folgenden Befehl ausführen:
openssh dhparam -C 2048
Es wird dadurch ein Schlüssel erzeugt (was einen Moment dauert), den man dann in eine Datei (bspw. nrpe_dh_2048.pem) speichert. Der Schlüssel beginnt mit -----BEGIN DH PARAMETERS-----
und Endet mit -----END DH PARAMETERS-----
. Die Datei wird dann im Zertifikatspfad vom NSClient++ abgelegt (bspw. C:\Program Files\NSClient++\security\)
Außerdem muss dann noch folgender Eintrag in den Abschnitt [/settings/NRPE/server]
der nsclient.ini eingetragen werden:
; DH KEY -
dh = ${certificate-path}/nrpe_dh_2048.pem
Nach einem Neustart des NSClient++ Dienstes kann NRPE auch wieder abgerufen werden.
Hilfreichste Quelle: https://help.univention.com/t/problem-nagios-ssl-issues-with-nsclient/11620
SSH und alte Cipher
Manche Systeme, die mit Nagios überwacht werden, haben ältere SSH-Versionen, die entsprechend veraltete Cipher benutzen. Bei mir war es u.a. ein Fujitsu Eternus. Fehlermeldung in Nagios war folgende:
[ssh return code = 255]
Eine Überprüfung via direkter SSH-Verbindung ergab, dass mein System nicht die nötigen Cipher anbietet:
Unable to negotiate with 192.168.2.3 port 22: no matching cipher found. Their offer: aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast1 28-cbc,3des-cbc,des-cbc,des-cbc,arcfour128,arcfour
Als Lösung habe ich einen der genannten Cipher (aes256-cbc) in der /etc/ssh/ssh_config hinzugefügt:
Ciphers +aes256-cbc
Anschließend war eine SSH-Verbindung zu dem betroffenen System wieder möglich und Nagios hat wieder korrekte Werte geliefert.