breakdown_security
Port Spotlightintermediate2 Min. Lesezeit

Port 22: SSH

Was offenes SSH über die Angriffsfläche eines Hosts verrät, und worauf ein Pentest-Scan gegen Port 22 wirklich achtet.

SSH ist der unauffälligste Port in jedem Scan-Ergebnis und gleichzeitig einer der wichtigsten. Wo Port 22 offen ist, gibt es fast immer administrativen Zugriff auf das darunterliegende System, nicht nur auf eine Anwendung. Ein kompromittierter SSH-Zugang ist selten “ein Account”, meistens ist es die Maschine.

Was beim Verbindungsaufbau sichtbar wird

Noch bevor Authentifizierung überhaupt möglich ist, tauschen Client und Server ihre Protokoll-Banner aus. Das reicht für einen ersten Fingerprint:

nc -nv 10.10.11.23 22

Eine Antwort wie SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu1 verrät SSH-Version, Implementierung und oft indirekt die Distribution samt Patch-Stand. Für die Aufklärung reicht das selten, es ist aber der erste Baustein, um offensichtlich veraltete oder gepatchte Builds zu unterscheiden.

Ein nmap-Scan mit den passenden Skripten liefert deutlich mehr:

nmap -p 22 -sV --script ssh2-enum-algos,ssh-auth-methods,ssh-hostkey 10.10.11.23

Drei Dinge daraus sind für die weitere Vorgehensweise relevant:

  • Unterstützte Auth-Methoden. Bietet der Server password an, ist Brute-Force oder Password Spraying überhaupt ein realistischer Weg (siehe Hydra und Password Spraying über SSH). Steht dort nur publickey, verschiebt sich der Fokus auf gestohlene oder schwache Private Keys.
  • Host-Key-Algorithmen. Verrät indirekt das Alter der OpenSSH-Version und ob veraltete, unsichere Algorithmen (z. B. ssh-rsa mit SHA-1) noch aktiv sind.
  • Angebotene Kex- und Chiffren-Algorithmen. Relevant für Schwachstellen-Scanner, die gegen bekannte CVEs in bestimmten Algorithmus-Kombinationen prüfen.

Typische Fehlkonfigurationen

In der Praxis ist Port 22 selten das eigentliche Problem, die Konfiguration dahinter ist es:

  • PasswordAuthentication yes ohne Rate-Limiting oder Lockout, kombiniert mit schwachen oder wiederverwendeten Passwörtern.
  • PermitRootLogin yes, teils sogar mit Passwort-Auth statt ausschließlich Key-based.
  • Dieselbe authorized_keys-Datei über viele Server verteilt, sodass ein einziger kompromittierter privater Schlüssel sich lateral durch die gesamte Umgebung bewegen kann.
  • Alte, aber noch erreichbare SSH-Daemons auf IoT- oder Management-Interfaces, die beim regulären Patch-Zyklus vergessen wurden.

Hardening-Tipp

PasswordAuthentication no plus ausschließlich Key-based Auth entzieht Brute-Force- und Spraying-Angriffen die Grundlage komplett. Wo Passwort-Auth aus Legacy-Gründen bleiben muss: fail2ban oder sshguard gegen wiederholte Fehlversuche, und MaxAuthTries niedrig halten.

Was ein Fund hier auslöst

Offenes SSH mit Passwort-Auth ist der Startpunkt für zwei der am häufigsten beobachteten Techniken gegen exponierte Linux-Hosts: Brute-Force gegen einen bekannten Benutzernamen und Password Spraying über eine Liste von Benutzernamen mit einem einzigen, wahrscheinlichen Passwort. Beide Artikel in dieser Reihe, der Tool-Teardown zu Hydra und die Angriffserklärung zum Password Spraying selbst, bauen direkt auf den Informationen auf, die ein einfacher Scan gegen Port 22 liefert.

#ssh#port-22#recon