Springe zum Inhalt

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:

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

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

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.