OTOthoTools
Language
enen-AUen-GBen-CAdede-CHithipt-BRnlno
⌁

sshd-Prüfer

SSH-Härtung kontrollieren
Eingabe
Ergebnis1 Befunde
  • ✓Kein kritisches Problem erkannt

Einführung

Der sshd-Prüfer liest eine eingefügte sshd_config und prüft fünf Kontrollen, die am häufigsten eine schwache SSH-Position verursachen: Root-Login, leere Passwörter, Passwort-Authentifizierung, Authentifizierungsversuche und X11-Forwarding.

Das Ziel ist nicht, eine Ideologie des SSH durchzusetzen — es geht darum, Einstellungen sichtbar zu machen, die zusammen darüber entscheiden, ob ein Angreifer brute-forcen oder ein legitimer Benutzer sich aussperren kann.

Ziel

  • PermitRootLogin-Werte erkennen, die direkten Root-Login erlauben.
  • Aktiviertes PermitEmptyPasswords erkennen, das passwortlose Konten zulässt.
  • Warnen, wenn PasswordAuthentication aktiviert bleibt, und Schlüsselzugriff empfehlen.
  • MaxAuthTries über 4 und X11Forwarding ohne erklärten Bedarf kennzeichnen.

Eingaben

  • Eine Einfügung von /etc/ssh/sshd_config (oder sshd -T-Ausgabe).
  • Kommentar- und Leerzeilen werden ignoriert; der erste Wert pro Schlüssel gewinnt.

So funktioniert es

Das Werkzeug parst jede Zeile in Schlüssel und Wert (ohne Gross-/Kleinschreibung) und behält das erste Vorkommen je Schlüssel — so, wie sshd seine Default-Datei anwendet.

Anschliessend vergleicht es jeden relevanten Schlüssel mit der gehärteten Erwartung: permitrootlogin muss no sein, permitemptypasswords muss no sein, passwordauthentication sollte no sein, maxauthtries muss 4 oder weniger sein und x11forwarding sollte no sein.

Root-Login und leere Passwörter gelten als hohe Schwere, weil sie die beiden wichtigsten Barrieren gegen Remote-Kompromittierung entfernen. Die übrigen Kontrollen sind Warnungen, weil ihr Idealwert von Ihrer Umgebung abhängt.

Testbares Beispiel

Ausprobieren — die Analyse läuft lokal in Ihrem Browser.

Beispiel

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 4
X11Forwarding no

Erwartete Ausgabe

PermitRootLogin no — OK.
PermitEmptyPasswords no — OK.
PasswordAuthentication no — OK.
MaxAuthTries 4 — OK.
X11Forwarding no — OK.
Ergebnis: kein kritisches Problem erkannt.

Ausgabe verstehen

  • Ein hoher Befund bedeutet, dass eine Einstellung das System aktiv schwächt; beheben, nachdem der Zugangsweg bestätigt ist (ein sudo-fähiger Benutzer mit funktionierendem Schlüssel).
  • Eine Warnung ist eine Empfehlung — etwa die Passwort-Authentifizierung erst zu deaktivieren, wenn der Schlüsselzugriff verifiziert ist.
  • Vor dem Neuladen von sshd immer mit einer zweiten SSH-Sitzung testen: systemctl reload ssh (oder service ssh reload).

Risiken

  • Die Deaktivierung der Passwort-Authentifizierung ohne konfigurierten Schlüssel kann Sie vom Server aussperren.
  • PermitRootLogin yes lädt gezieltes Brute-Forcing auf das wertvollste Konto der Maschine ein.
  • sshd_config ohne offene zweite Sitzung zu ändern ist der klassische Weg, den Remote-Zugriff zu verlieren.

Grenzen

  • Das Werkzeug liest nur eingefügten Text, nicht Ihre echte Konfigurationsdatei.
  • Es prüft eine Handvoll Kontrollen, keine vollständige SSH-Prüfung.
  • Es kann fehlkonfigurierte Authentifizierungsmethoden, schwache Host-Keys oder SSH-Agent-Probleme nicht erkennen.

Offizielle Referenzen

FAQ

Ist das Deaktivieren der Passwort-Authentifizierung immer richtig?

Für internetzugängliche Server fast immer — aber nur, nachdem der Schlüssel-Login aus einer zweiten Sitzung verifiziert wurde. In manchen verwalteten Umgebungen müssen Sie die Passwort-Auth für eine Bastion behalten.

Was ist ein sicherer MaxAuthTries-Wert?

CIS empfiehlt 4 oder weniger. Niedrigere Werte verlangsamen Brute-Force, können aber legitime Benutzer mit fehlkonfigurierten Agenten stören.

Prüft das Werkzeug meine echte sshd_config?

Nein — nur den eingefügten Text. Die echte Quelle ist /etc/ssh/sshd_config plus Dateien unter /etc/ssh/sshd_config.d/, die Sie mit sshd -T zusammenführen können.