Trotz erfüllter Bedingungen: TLS is not activated on monitored host

[Frankenstein]

Moin Leute,

alles brav nach Anleitung eingerichtet.

• CheckMK aufm Control Node installiert
• Site erstellt
• Site gestartet und Passwort geändert
• CheckMK Webinterface mit Lets Encrypt Zertifikat abgesichert
• Rewrite von http → https eingerichtet
• Agent auf allen Monitored Hosts installiert
• Alle Hosts angelegt mit Hostname und IP Adresse
• folgenden Register Befehl benutzt

cmk-agent-ctl register --hostname app-a.domain.de --server monitor.domain.de --site monitoring --user cmkadmin

Wie hier beschrieben, sollten alle Bedingungen für eine TLS encryption erfüllt sein

Monitoring Linux - The new agent for Linux in detail

root@app-a:~# systemctl --version
systemd 249 (249.11-0ubuntu3.6)

root@app-a:~# cmk-agent-ctl --version
cmk-agent-ctl 2.1.0p20

root@app-a:~# ss -tulpn | grep 6556
tcp   LISTEN 0      4096                                 *:6556            *:*    users:(("cmk-agent-ctl",pid=22909,fd=9))

root@app-a:~# cmk-agent-ctl status
Version: 2.1.0p20
Agent socket: operational
IP allowlist: any


Connection: monitor.domain.de:8000/monitoring
        UUID: 12345678-1234-1234-1234-123456789012
        Local:
                Connection type: pull-agent
                Certificate issuer: Site 'monitoring' local CA
                Certificate validity: Fri, 27 Jan 2023 14:26:17 +0000 - Wed, 30 May 3021 14:26:17 +0000
        Remote:
                Connection type: pull-agent
                Registration state: operational
                Host name: app-a.domain.de

Jetzt frag ich natürlich…Warum kriege ich trotzdem für jeden Host (außer den Control Node selbst) folgende WARNING:

Version: 2.1.0p20, OS: linux, TLS is not activated on monitored host (see details)WARN, Agent plugins: 0, Local checks: 0

Würde mich freuen, wenn ihr mir da ein Hinweis geben könntet. Liegt es daran, dass ich den cmkadmin genutzt habe zum registrieren statt automation? Laut diversen Videos von CheckMK selbst wird dort auch immer wird der cmkadmin genutzt.

[mschlenker (Mattias Schlenker)]

Liefert

echo | nc host.im.monitoring 6556

als Ausgabe nur “16” oder die Agentenausgabe im Klartext?

[white_rabbit (Michael)]

Hallo.
Kann es sein, dass der Client bzw das zu überwachende Gerät vorher schon lief und vorher ohne TLS eingebunden war? Da hatte ich auch schon Probleme und musste den checkMK-Agent vollständig entfernen und nochmal neu anfangen.
Wie das im Detail ging, habe ich hier gefunden:

[agent] Host is registered for TLS but not using it, Got no information from host

Hi Christian, thank you for your time. I have solved the problem. Please also add this to your troubleshooting documents, as many people have the same problem. Before you install the agent on Linux. Linux administrator should disable the “Xinetd service”. The following guide will hopefully help others. Stop Xinetd service Stop all agent controller services Uninstall the agent controller on the host Delete all directories/files of the agent controller from the host Install a clean installatio…

Danach funktionierte der Check auch über TLS… ob das der empfohlene Weg ist, kann ich nicht sagen aber: wfm!

Was übrigens den User “automation” angeht: Den hatte ich bisher auch verwendet aber neuerdings lief das nicht mehr, weil angeblich das (neu gesetzte!) Passwort nicht wollte. Danach habe ich dann den checkMK-Admin-Login verwendet, der problemlos funktioniert hat!

hth.

[mschlenker (Mattias Schlenker)]

Falsch ist dieses Vorgehen nicht, es ist halt etwas umständlicher als eigentlich nötig. Und in diesem Fall lauscht auch der Agent Controller an Port 6556 und nicht xinetd. Also entweder ist da die allow_legacy_pull Datei liegen geblieben oder einfach ein Neustart des Dienstes cmk-agent-ctl-daemon nötig. Falls letzteres der Fall sein sollte, muss ich den Kollegen in der Entwicklung möglicherweise eine Regression melden.