SSH

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.

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.

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.

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.

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.