blueredix logo
SCAN Schwachstellenscans auf Abruf ab 149 €
info service-ssh-cve

Schwachstellen in OpenSSH

OpenSSH ist auf praktisch jedem Linux-Server am Netz der zentrale Fernzugang. Die wirklich ernsten Bugs sind selten; gleichzeitig produziert reines Versions-Matching viel Rauschen. Wie man SSH-Befunde sinnvoll liest.

Warum SSH-Befunde besonderer Lesart bedürfen

OpenSSH läuft auf praktisch jedem Linux-Server am Netz. CVEs darin sehen in Scan-Berichten entsprechend bedrohlich aus und brauchen fast immer einen zweiten Blick, bevor Panik einsetzt.

Zwei Gründe:

  1. Wirklich ernste Bugs in OpenSSH sind selten. Bugs, die einem Angreifer die Übernahme eines SSH-Servers ohne Account ermöglichen, kommen alle paar Jahre. regreSSHion (CVE-2024-6387) aus 2024 war der erste praxistaugliche dieser Art seit langem, und auch diese Lücke war eine knifflige Timing-Race-Condition, die Tausende Verbindungsversuche für eine zuverlässige Ausnutzung benötigte.
  2. Die meisten OpenSSH-Server werden von ihrer Distribution gepflegt. Ubuntu, Debian, RHEL, SUSE und Amazon Linux backporten Sicherheitsfixes auf eine stabile Upstream-Version. “OpenSSH 9.6p1” auf Ubuntu 24.04 hat die Patches für die Bugs des Upstream-9.6p1; die lange Liste an CVEs, die öffentliche Datenbanken für 9.6p1 ausweisen, ist auf Ihrer Maschine also meist längst behoben. Reines Versions-Matching produziert eine Flut Falschpositiver.

Der blueredix-Scanner bedient beides. Distro-getaggte Builds überspringen den Datenbank-Lookup mit einer Info-Level-Notiz “distribution-managed”, und ein Anwendbarkeits-Filter wirft CVEs raus, deren verwundbare Beschreibung Ihre Version nicht mit expliziten Versions-Grenzen abdeckt.

Wann ein OpenSSH-CVE-Befund wirklich ernst ist

Zuerst auf das Flag distribution-managed schauen.

  • Distro-managed und KEV-Flag oder EPSS > 0,3. Ein bekannt ausgenutzter Bug existiert; Sie müssen prüfen, ob die Distribution den Fix ausgeliefert hat. Im Sicherheits-Tracker (USN, DSA, RHSA) nach der CVE-ID suchen und sicherstellen, dass das installierte Paket auf oder über der gepatchten Version liegt. Auf Ubuntu reichen apt list --installed openssh-server plus der Hinweistext.
  • Distro-managed, kein KEV / niedriges EPSS. Die Distribution zieht das im regulären Security-Stream nach. Patch einplanen, kein Feueralarm.
  • Nicht distro-managed (Custom-Build, Vendor-Appliance). CVE-Beschreibung lesen. Pre-Auth oder Post-Auth? Pre-Auth ist selten genug, um Out-of-Band zu rechtfertigen; Post-Auth ist auf einem sauber konfigurierten Server deutlich weniger dringend.

Pre-Auth vs. Post-Auth

OpenSSH hat zwei klar getrennte Angriffsflächen:

  • Pre-Authentication. Der Angreifer braucht nur Netzwerkzugang zum SSH-Port. Bugs hier haben universellen Impact: jeder im Netz sichtbare Server der betroffenen Version ist gefährdet. CVE-2024-6387 (regreSSHion) ist das aktuelle Beispiel.
  • Post-Authentication. Der Angreifer ist bereits eingeloggt. Bugs hier erlauben jemandem, der nicht eskalieren sollte, doch zu eskalieren. In Verbindung mit schwachem SSH-Key-Management problematisch, sonst weniger.

Für unauthentifizierte Angreifer im offenen Netz zählen Pre-Auth-Bugs. Viele bedrohlich klingende OpenSSH-CVE-Beschreibungen entpuppen sich als “Post-Auth-Memory-Bug mit Privilege-Separation-Impact” oder “lokal-seitiger Bug in ssh-agent”, sobald man über die Überschrift hinausliest.

SSH-Härtung unabhängig von CVEs

Die meisten realen SSH-Kompromittierungen kommen nicht aus OpenSSH-CVEs, sondern aus schwachen Credentials. Egal, was der Scanner sagt:

  1. Passwort-Authentifizierung deaktivieren. PasswordAuthentication no in sshd_config. Nur Public Keys.
  2. root-Login deaktivieren. PermitRootLogin no. Wenn root nötig, per sudo aus einem unprivilegierten Account.
  3. An eine konkrete IP binden, falls öffentliches SSH nicht nötig ist (ListenAddress 10.0.0.5). Die wirksamste Verteidigung ist “der Dienst ist von dort, wo die Angreifer sitzen, nicht erreichbar”.
  4. Brute-Force-Schutz wie Fail2Ban oder CrowdSec auf internet-exponierten Servern. Stoppt einen versierten Angreifer nicht, senkt aber das Grundrauschen um 99 %.
  5. ed25519-Keys statt RSA bei Neugenerierung: kleiner, schneller und ohne die theoretischen Risiken kurzer RSA-Keys.

Wie blueredix SSH-Befunde meldet

Der Scanner zeigt:

  • Erkannte Version und Patch-Suffix (OpenSSH 9.6p1 Ubuntu 3ubuntu13.4).
  • Erkannte Distribution, sofern erkennbar.
  • Entweder eine Liste anwendbarer CVEs (gefiltert wie oben) oder eine einzelne Info-Level-Notiz “distribution-managed” mit Verweis auf den Distro-Sicherheits-Tracker.

Sehen Sie eine lange Liste CVEs aus der Zeit vor 2020 gegen ein modernes OpenSSH, hat der Anwendbarkeits-Filter bereits viel von dem gestrichen, was die öffentliche Datenbank ursprünglich geliefert hat. Mechanismus siehe Wie man eine CVE liest.

Mehr dazu