Springe zum Inhalt

In der Monitoring-Software Zabbix gibt es die Möglichkeit, aufzuzeichnende Werte über Shell-Komandos zu ermitteln, die über SSH von einem enfernten Host gesammelt werden. Dazu muss sich der auf dem jeweiligen Host für die Datensammelei installierte Zabbix-Agent per SSH mit dem entfernten Rechner verbinden können. Passwortlos funktioniert das am besten mit dem in SSH integrierten Public-Key-Verfahren: dazu erstellt man zuerst für den Benutzer, unter dem der Zabbix-Agent läuft einen SSH-Key mit ssh-keygen, schickt dann den generierten öffentlichen Schlüssel an den entfernten Rechner und trägt diesen beim Benutzer in der Datei ~/.ssh/authorized_keys ein. Die letzten zwei Schritte kann man auch halbautomatisch mit dem Befehl ssh-copy-id erledigen.

Danach sollte sich der Zabbix-Agent-Benutzer mit "ssh <Remote-Host>" ohne Passworteingabe auf dem Remote-Host anmelden können. Anschließend können die zu überwachenden Werte in Zabbix konfiguriert werden.

Groß ist die Verwunderung, wenn Zabbix im Status des jeweiligen Wertes "Public key authentification failed" anzeigt, obwohl der manuelle Verbindungsaufbau problemlos funktioniert hat.

Ursache ist, dass ssh-key-gen jetzt standardmäßig Keys im OpenSSH-Format und nicht mehr im alten RSA-Format erstellt. Zu erkennen ist das neue Format in der Datei ~/.ssh/id_rsa. Für OpenSSH steht dort "-----BEGIN OPENSSH PRIVATE KEY-----" und für RSA "-----BEGIN RSA PRIVATE KEY-----" in der ersten Zeile. Zumindest meine Zabbix-Version (4.0) kann noch nicht mit dem OpenSSH-Format umgehen und verwendet den entsprechenden Schlüssel dann einfach nicht. Resultat: Public key authentification failed.

Abhilfe schafft das Kommando "ssh-keygen -m PEM", welches einen neuen Schlüssel im alten Format erzeugt, das auch ältere Zabbix-Version verstehen.

Nach dem Update von Stretch auf Buster braucht OpenSSH, speziell auf VMs, schon mal gerne mehrere Minuten zum Starten. Grund dafür ist, dass systemd alle Dienste ziemlich parallel startet und für OpenSSH-Verschlüsselungsroutinen einfach noch nicht genug Entropie vorhanden ist. OpenSSH wartet deshalb erst einmal ab und lässt noch keine Verbindungen von außen zu. Erst wenn im Kernel-Log die Meldung "random: crng init done" auftaucht, ist die Initialisierung abgeschlossen und OpenSSH startet komplett.

Probleme beim Systemstart betreffend der noch nicht vohandener Entropie können auch bei Webservern auftreten, die wiederrum SSL-Bibliotheken verwenden und diese ebenfalls noch nicht initialisieren können.

Eine einfache Lösung für diese Probleme ist die Installation von haveged, einem User-Space-Daemon, welcher beim Systemstart Entropie liefert, sobald der "Füllstand" von /dev/random unter eine gewisse Grenze fällt.

Siehe hierzu auch: