Springe zum Inhalt

Schlagwort: SSH

Veröffentlicht am

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.

Veröffentlicht am

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:

Veröffentlicht am

Heute bin ich gleich zwei Mal über das Python-Modul Paramiko gestolpert. In der MySQL-Workbench wird es verwendet, um eine Verbindung über einen SSH-Tunnel herzustellen. Das in der aktuellen MySQL-Workbench ausgelieferte, aber uralte Paramiko versteht sich nicht mehr mit aktuellen OpenSSH-Versionen. Nach einem manuellen Update von Paramiko funktionierte der Verbindungsaufbau dann wieder.

Die zweite Portion Paramiko gab es beim Durchsehen der Backups. Das von mir verwendete Duplicity benutzt ebenfalls Paramiko, wenn Backups auf einem per SSH bzw. SFTP oder SCP erreichbaren Server abgelegt werden sollen. Leider funktioniert SFTP und SCP in Duplicity, und damit implizit Paramiko, aktuell nicht mit einem Backup-Server bei Hetzner. Eine Lösung habe ich bisher leider nicht gefunden.

3

Veröffentlicht am 3 Kommentare zu MySQL-Workbench: SSH-Tunnelaufbau scheitert

Nach einem Update eines Servers auf Debian 8 Jessie war ein Verbindungsaufbau von einer MySQL-Workbench über einen SSH-Tunnel zu diesem Server nicht mehr möglich. Das Logfile der MySQL-Workbench (unter Windows in %APPDATA%\MySQL\Workbench\log\wb.log zu finden) enhält folgende Fehlermeldung:

SSHException: Incompatible ssh peer (no acceptable kex algorithm)

Grund für die Fehlermeldung ist, dass das in der aktuellen MySQL-Workbench 6.3 CE verwendete Python-Modul (paramiko), welches für den Verbindungsaufbau über einen SSH-Tunnel zuständig ist, sich in der Version 1.7.7.1 nicht mehr mit der nun auf dem Server installierten OpenSSH-Version 6.7 versteht. ...weiterlesen "MySQL-Workbench: SSH-Tunnelaufbau scheitert"

4

Veröffentlicht am 4 Kommentare zu Verschlüsselten Root- oder vServer einrichten

Beim Mieten eines Root- oder vServers von einem Hoster oder, wenn der eigene Server bei einem Hoster untergestellt werden soll (Co-Location) hat man ein Problem: der Server ist nicht unter eigener Kontrolle, Mitarbeiter des Hosters können darauf zugreifen, im schlimmsten Fall Daten ändern oder kopieren. Bei vServern ist dieser Angriff releativ einfach, da die gängigen Systeme problemlos einen Snapshot der vServer-Festplatten erstellen können, die dann von bösen Buben in Ruhe ausgewertet werden können. Bei Root-Servern wird meistens ein vom Hoster geliefertes Kernelimage installiert, dessen Quellcode nicht offenliegt, die gesamte Funktionalität also nicht bekannt ist und somit auch z.B. Keylogger enthalten könnte.

Linux hat auch für diese Problemefälle eine Lösung: verschlüsselte Partitionen. Problematisch ist, dass das zur Entsperrung der Partitionen benötigte Passwort beim Bootvorgang eingegeben werden muß. In einer Schritt-für-Schritt-Anleitung beschreibt Falk Husemanns, wie ein beim Hoster stehender Server von Grund auf mit einem Standardkernel und verschlüsselten Partitionen eingerichtet werden kann. Sollte der Server einmal gebootet werden müssen, kann bei dieser Lösung das Passwort zum Entsperren in einer SSH-Shell eingegeben werden.

Ebenfalls sind im Artikel weitere Werzeuge aufgelistet, mit denen sich Angriffe durch den Hoster erkennen lassen.

BTW: Dieser Text wird von einem Host geliefert, der nach obiger Anleitung eingerichtet wurde.