SSH-Server-Konfiguration härten
Zuletzt aktualisiert:
Die Datei sshd_config ist die gesamte Sicherheitslage Ihres SSH-Servers in einer einzigen Textdatei — und auf den meisten Systemen wird sie in einem Zustand ausgeliefert, der auf Kompatibilität optimiert ist, nicht auf Sicherheit. Passwort-Login ist standardmäßig aktiviert, Root darf sich anmelden, solange ein Schlüssel verwendet wird, inaktive Sitzungen laufen nie ab, und die Algorithmen, die Ihr Server anbietet, sind die, die die vor Jahren installierte OpenSSH-Version festgelegt hat. Härten heißt nicht, eine Checkliste von 2021 zu kopieren: Algorithmen werden entfernt, Standardeinstellungen ändern sich, und eine Konfiguration, die vor fünf Jahren vorbildlich war, kann heute schwach sein. Dieser Artikel erklärt, was jede Änderung tatsächlich bewirkt, warum die Reihenfolge Ihrer Entscheidungen wichtig ist und wie man eine neue Konfiguration testet, ohne sich auszusperren. Ihre eigene Datei können Sie Zeile für Zeile im SSH-Server-Konfigurations-Auditor prüfen, der sie mit einer Basislinie vom 2026-11-13 vergleicht — vollständig in Ihrem Browser.
Standardeinstellungen sind ein Ausgangspunkt, keine Härtung
OpenSSH wird mit Standardeinstellungen ausgeliefert, die so gewählt sind, dass eine Neuinstallation für möglichst viele Menschen funktioniert — und genau deshalb sind sie keine Sicherheitslage. Zu den aktuellen Standardeinstellungen gehören laut Manpage der sshd_config unter anderem PasswordAuthentication yes, PermitRootLogin prohibit-password, MaxAuthTries 6, LoginGraceTime 120 Sekunden und ClientAliveInterval 0, was bedeutet, dass inaktive Sitzungen nie beendet werden. Keiner davon ist ein Fehler: Jeder ist eine bewusste Kompatibilitätsentscheidung, und jeder ist ein Befund in einem Härtungs-Audit.
Die praktische Folge: Ein Server, den niemand je gehärtet hat, ist weiterhin durch Passwortraten erreichbar, akzeptiert weiterhin Root-Logins mit einem gestohlenen Schlüssel und lässt verlassene Sitzungen unbegrenzt offen. Auch die Standardeinstellungen ändern sich im Laufe der Zeit — was OpenSSH 10.6 mitbringt, ist nicht das, was OpenSSH 7 mitbrachte —, also ist „Ich habe nie etwas geändert" keine neutrale Aussage. Sie bedeutet, dass Ihre Sicherheitslage die ist, die die zufällig installierte Version festgelegt hat, und der einzige Weg, das zu wissen, ist, die Datei zu lesen. Das ist die erste Aufgabe eines Audits: die unsichtbaren Standardeinstellungen sichtbar zu machen, denn eine Direktive, die in der Datei fehlt, gilt trotzdem.
Passwörter abschalten schlägt Portwechsel — jedes Mal
Die wirksamste einzelne Änderung in der sshd_config ist PasswordAuthentication no in Kombination mit PubkeyAuthentication yes: Ab diesem Moment kann kein Passwort — erraten, geleakt oder per Phishing gestohlen — eine Sitzung öffnen, weil der Daemon diese Art von Nachweis gar nicht mehr akzeptiert. Die Schlüssel-Authentifizierung verwandelt den Angriff von „ein Geheimnis erraten, das ein Mensch gewählt hat" in „eine private Schlüsseldatei stehlen, die nie das Netzwerk überquert", und deshalb beginnt jede Härtungs-Basislinie, einschließlich der von Mozilla, hier. Wenn Sie aus diesem Artikel nur eines mitnehmen, dann dieses: Erzeugen Sie ein Schlüsselpaar (siehe SSH-Schlüssel-Suite und den Begleitartikel SSH-Schlüssel erklärt), installieren Sie den öffentlichen Schlüssel, prüfen Sie, dass Sie sich damit anmelden können, und schalten Sie erst dann die Passwörter ab.
Den Port von 22 auf etwas Obskures zu ändern, ist dagegen keine Härtung — es ist Verschleierung. Es reduziert das Rauschen in Ihren Logs, weil die meisten Internet-weiten Scanner nur an Port 22 klopfen, aber es stoppt keinen Angreifer, der sich die Mühe macht zu scannen: Ein Portscan findet den Daemon in Sekunden, und der Daemon dahinter ist genau so stark wie seine Konfiguration. Der Auditor behandelt einen Port ungleich 22 daher nur als Information, nie als bewertete Verbesserung. Eine Falle sollte man kennen, bevor man den Schalter umlegt: Auf Systemen mit PAM reicht PasswordAuthentication no allein nicht aus — die Tastatur-interaktive Authentifizierung kann PAM weiterhin ein Passwort akzeptieren lassen, also muss auch der PAM-Stack in /etc/pam.d/sshd Passwörter verweigern. Die Richtlinien von Mozilla sagen das ausdrücklich, und es ist die am häufigsten übersehene zweite Hälfte der Änderung.
Root-Login: was prohibit-password wirklich erlaubt
PermitRootLogin hat vier Werte, und der Unterschied zwischen ihnen ist der Unterschied zwischen einer Audit-Spur und keiner. Der Standardwert prohibit-password erlaubt Root die Anmeldung — nur eben nicht mit Passwort. Ein gestohlener Root-Schlüssel geht trotzdem ungehindert hinein, und sobald die Sitzung Root ist, unterscheidet nichts in den Logs einen Administrator vom anderen. Das Modern-Profil von Mozilla setzt den Wert auf No, und das ist die gehärtete Antwort: Root sollte niemals ein Login-Konto sein. Melden Sie sich als benannter Benutzer an und nutzen Sie sudo; dann ist jede privilegierte Aktion einer Person zuordenbar.
Die Zwischenwerte gibt es aus gutem Grund, und man sollte sie kennen statt fürchten. forced-commands-only erlaubt Root-Login nur, wenn der angebotene Schlüssel in authorized_keys auf einen einzigen Befehl beschränkt ist — das Muster, das Backup- und Monitoring-Skripte verwenden — und ist eine legitime, bewusste Wahl für Automatisierung. Was nicht legitim ist, ist yes: Es erlaubt Root-Login mit Passwort und ist in jedem Audit ein Fehler. Die praktische Regel: Wenn sich ein Mensch als Root anmeldet, ist die Konfiguration falsch; wenn es ein Skript tut, beschränken Sie den Schlüssel auf einen Befehl und schreiben Sie es in einen Kommentar, denn die nächste Person, die die Datei liest, wird ihn sonst „reparieren".
Die Abschaffung von Algorithmen ist ein bewegliches Ziel
Die Algorithmen in Ihrer Konfiguration haben ein Verfallsdatum, und es ist kürzer, als Sie denken. OpenSSH 10.0, veröffentlicht am 2025-04-09, hat die DSA-Unterstützung (ssh-dss) vollständig entfernt, das Diffie-Hellman über endliche Körper aus dem Standard-Schlüsselaustausch des Servers genommen und mlkem768x25519-sha256 — einen post-quantensicheren Hybrid — zum Standard-Schlüsselaustausch gemacht. Eine Konfiguration, die von einem Blogbeitrag aus 2021 kopiert wurde, listet möglicherweise noch diffie-hellman-group1-sha1, 3des-cbc, arcfour oder hmac-md5 — in einem modernen Audit allesamt Fehler, von denen einige der installierte Daemon nicht einmal mehr unterstützt. Die Konfiguration hat sich nicht geändert; die Welt schon.
Deshalb muss eine Härtungs-Basislinie ein Datum tragen, und deshalb ist erneutes Prüfen Teil der Arbeit, kein nachträglicher Gedanke. Das Modern-Profil von Mozilla — curve25519-Schlüsselaustausch, chacha20-poly1305- und AES-GCM-Chiffren, SHA-2-Encrypt-then-MAC — ist die Referenz, aber es ist älter als die post-quantensicheren Schlüsselaustausche, die OpenSSH 10.0 zum Standard gemacht hat, sodass ein Audit von 2026 daneben auch mlkem768x25519-sha256 und sntrup761x25519-sha512 akzeptiert. Die Gewohnheit, die Sie aktuell hält, ist billig: Ein- bis zweimal im Jahr führen Sie ssh -Q kex, ssh -Q cipher und ssh -Q mac auf dem Server aus, um zu sehen, was die installierte Version tatsächlich anbietet, vergleichen das mit den aktuellen Mozilla-Richtlinien und lassen den Auditor erneut über dieselbe Datei laufen. Ein sauberer Score von 2021 ist ein historisches Dokument, kein aktuelles.
Match-Blöcke und Include: die zwei Arten, wie ein sauberes Audit lügt
Eine Konfigurationsdatei ist keine flache Liste von Einstellungen — sie ist ein Programm mit bedingten Verzweigungen, und zwei Funktionen können dazu führen, dass eine Datei, die sich gehärtet liest, sich verhält, als wäre sie es nicht. Die erste ist der Match-Block: Direktiven innerhalb von Match User, Match Group oder Match Address gelten nur, wenn die Kriterien erfüllt sind, und die Manpage ist eindeutig: Wenn ein Schlüsselwort in mehreren erfüllten Match-Blöcken vorkommt, wird nur die erste Instanz angewendet. Ein globales PasswordAuthentication no, gefolgt von einem Match-Block, der für eine Gruppe leise wieder Passwörter aktiviert, ist eine reale Konfiguration — und genau die Art von Sache, die ein zeilenweises Lesen übersieht. Befunde aus einem Match-Block sind bedingt, niemals global, und jedes ehrliche Audit kennzeichnet sie so.
Die zweite ist Include. Moderne Distributionen teilen die sshd_config auf mehrere Dateien auf — /etc/ssh/sshd_config.d/*.conf ist das übliche Muster — und eine Include-Direktive zieht diese Dateien in lexikalischer Reihenfolge an der Stelle ein, an der sie steht. Da der zuerst erhaltene Wert gewinnt, überschattet eine Direktive, die in einer eingebundenen Datei gesetzt ist, dieselbe Direktive weiter unten in der Hauptdatei: Die Zeile, die Sie lesen, ist nicht die Zeile, die gilt. Ein Auditor, der im Browser läuft, kann Includes nicht verfolgen — die Dateien liegen nicht auf Ihrem Rechner —, also markiert er sie als „nicht verfolgt" und listet den Pfad. Wenn Sie auditieren, auditieren Sie das ganze Verzeichnis, nicht nur eine Datei, und denken Sie daran: Eine doppelte Direktive ist kein Tippfehler, den man ignorieren kann: Die erste gewinnt, und die zweite ist toter Text, der die nächste Person verwirren wird, die die Datei bearbeitet.
Das sichere Ausrollen: testen, bevor Sie die Tür schließen
Jede Änderung an der sshd_config birgt dasselbe Risiko: Ein Tippfehler kann verhindern, dass der Daemon neu startet, und eine korrekte, aber falsche Einstellung kann Ihnen den Zugang verweigern. Das Ausrollen, das beides vermeidet, ist kurz und nicht verhandelbar. Prüfen Sie zuerst mit sshd -t die Syntax, bevor Sie den laufenden Dienst anfassen — es parst die Datei und meldet Fehler, ohne etwas zu starten. Starten Sie dann den Daemon neu oder laden Sie ihn neu, und testen Sie erst dann. Bearbeiten Sie niemals die Konfiguration und schließen Sie im selben Atemzug Ihre einzige Sitzung.
Der Test selbst ist die Disziplin: Halten Sie Ihre bestehende Sitzung offen, öffnen Sie eine zweite Sitzung und melden Sie sich mit den neuen Regeln neu an. Wenn die zweite Anmeldung funktioniert, ist die Änderung sicher und die erste Sitzung kann geschlossen werden; wenn nicht, ist die offene Sitzung Ihr Weg zurück, und Sie können die Datei zurücksetzen und neu laden. Deshalb sollten Änderungen auf einem Server, den Sie nicht physisch erreichen können, auch immer einzeln vorgenommen werden — eine kaputte Schlüsseldatei und eine deaktivierte Passwortmethode in derselben Änderung lassen überhaupt keinen Rückweg. Der Auditor kann eine gehärtete Version Ihrer Datei als Ausgangspunkt erzeugen, aber es ist ein Entwurf, der Match-Block für Match-Block zu prüfen und mit sshd -t zu testen ist — niemals eine Datei, die man ungeprüft einsetzt.