SSH-Server auf Sicherheitslücken prüfen und härten

Warum eine SSH-Konfigurationsprüfung nicht optional ist

Ein SSH-Daemon mit Standardeinstellungen lässt häufig Algorithmen zu, die längst als gebrochen oder strukturell schwach gelten. Schwachstellen im SHA-1-basierten Host-Key-Algorithmus ssh-rsa, in CBC-Chiffren oder in Diffie-Hellman-Gruppen unter 2048 Bit erlauben theoretische und teilweise praktische Angriffe auf den Schlüsselaustausch. Hinzu kommen Lücken in der Authentifizierungslogik einzelner Server-Implementierungen.

Ein Administrator, der die SSH-Oberfläche seiner Server nicht regelmäßig untersucht, übersieht Risiken und Schwachstellen im laufenden Betrieb. Domänencontroller (DC) mit Samba-Backend stellen in so einem Umfeld ebenfalls eine Gefahr dar, denn ein Übernahmeangriff auf den DC öffnet den Weg in die gesamte Domäne. Eine kompromittierte SSH-Sitzung gegen einen Host bedeutet die Übernahme des Identitätskerns im Netzwerk. Skript-Sammler wie SSH-Snake (ein automatisierter Wurm, der sich über gestohlene SSH-Schlüssel im Netzwerk ausbreitet) stellen in diesem Zusammenhang ebenfalls eine Gefahr dar, die sich mit kostenlosen Tools aber minimieren lässt

ssh-audit als zentraler Konfigurations-Scanner

ssh-audit von jtesta wird über

pip3 install ssh-audit

oder

snap install ssh-audit

oder

sudo apt install ssh-audit

oder als Docker-Image positronsecurity/ssh-audit installiert. Die Anwendung benötigt Python 3.9 bis 3.13 und keine externen Abhängigkeiten. Ein Standardlauf gegen den Samba-DC im Beispielnetzwerk sieht so aus:

ssh-audit 10.0.5.10

Die Ausgabe gliedert sich in Banner, Software- und OS-Erkennung, Kompressionsstatus, Schlüsselaustausch-Algorithmen, Host-Key-Algorithmen, Chiffren und MAC-Algorithmen.

Jeder Algorithmus wird mit dem Tag info, warn oder fail markiert. Ein Scan gegen einen FreeBSD-Host mit OpenSSH 8.6 zeigt zum Beispiel in Abbildung 1, dass ecdh-sha2-nistp256, ecdh-sha2-nistp384 und ecdh-sha2-nistp521 als fail gekennzeichnet sind, da die zugrundeliegenden NIST-Kurven als kryptografisch problematisch gelten.

ssh-rsa wird wegen SHA-1 ebenfalls als fail markiert. Die Sektion rec listet konkrete Vorschläge zum Entfernen unsicherer Algorithmen. Mit der Option -v lassen sich verbose-Ausgaben einschalten, mit -j oder -jj erhält man JSON-Ergebnisse für die Weiterverarbeitung in SIEM- oder Reporting-Systemen. Der Parameter -l fail reduziert die Ausgabe auf die schwerwiegenden Funde, ideal für CI-Pipelines.

Für Audits jenseits einzelner Hosts gibt es noch die Option -T zusammen mit einer Datei, die eine Zeile pro Ziel im Format HOST[:PORT] enthält. Im Netz 10.0.0.0/16 lässt sich eine solche Liste aus dem ARP-Cache des Gateways 10.0.0.10 oder aus einem vorgelagerten Nmap-Scan generieren. Der Aufruf

ssh-audit -T targets.txt --threads 32

untersucht parallel bis zu 32 Hosts. Der Parameter --threads steuert die Parallelität und vermeidet Verbindungstimeouts in größeren Subnetzen.

Policy-Audits und Hardening-Guides

Ein reiner Algorithmus-Scan zeigt Schwächen, beantwortet aber nicht die Frage, ob ein Server einer definierten Härtungsvorgabe folgt. Dazu liefert ssh-audit eingebaute Profile. Mit dem Aufruf

ssh-audit -L

erscheint eine Liste der mitgelieferten Server- und Client-Policies, darunter Hardened OpenSSH Server v8.5 bis v10.0 und Hardened Ubuntu Server 16.04 LTS bis 24.04 LTS sowie Profile für Debian 12 und Debian 13. Die Anwendung gegen den Samba-DC in diesem Beispiel erfolgt über:

ssh-audit -P "Hardened Ubuntu Server 22.04 LTS (version 1)" 10.0.5.10

Die Ausgabe markiert jeden abweichenden Algorithmus mit fail. Eigene Policy-Dateien lassen sich mit -M aus einem als Referenz dienenden Host erzeugen, anschließend bearbeiten und über -P auf weitere Server anwenden. Die Direktive allow_algorithm_subset_and_reordering gestattet abweichende Reihenfolgen und Teilmengen, die Direktive allow_larger_keys lässt größere Host-Keys oder DH-Moduli zu. Für die Härtung selbst stellen die aktuellen Versionen eingebaute Hardening-Guides bereit, abrufbar über --list-hardening-guides und --get-hardening-guide.

Eine konkrete Härtung des Samba-DC in diesem Beispiel erfolgt über eine Drop-in-Datei unter /etc/ssh/sshd_config.d/ssh-audit_hardening.conf mit Einschränkungen für KexAlgorithms, Ciphers, MACs und HostKeyAlgorithms. Ein typischer Inhalt umfasst curve25519-sha256, [email protected], diffie-hellman-group16-sha512 und diffie-hellman-group18-sha512 als KEX, [email protected] sowie [email protected] als Chiffren und [email protected] sowie [email protected] als MACs. Vor dem Restart prüft

sshd -t

die Syntax. Auf einem laufenden Remote-System bietet sich

systemctl reload ssh.service

oder ein SIGHUP an den Eltern-Prozess an, da ein restart bestehende Sitzungen beendet.

DHEat-Test und Terrapin-Erkennung

Mit der Option --dheat führt ssh-audit den DoS-Angriff CVE-2002-20001 gegen einen Zielhost. Der Aufruf

ssh-audit --dheat=10:diffie-hellman-group-exchange-sha256:4 10.0.5.10

öffnet zehn parallele Sockets, sendet künstlich kurze e-Werte und erzwingt CPU-Last über asymmetrische Berechnungen. Der Parameter --conn-rate-test misst die Verbindungsrate des Daemons, --skip-rate-test schaltet diese Messung ab. Die Terrapin-Lücke wird im Standard-Scan durch eine zusätzliche Markierung an Chacha20-Poly1305 und CBC-EtM-Modi sichtbar.

ssh-keyscan zur Host-Key-Inventur

Mit ssh-keyscan rufen Admins den öffentlichen Host-Key des Servers ab, ohne eine Authentifizierung zu starten. Der Aufruf

ssh-keyscan -t rsa,ecdsa,ed25519 10.0.5.10

liefert alle vom Server angebotenen Host-Keys in der Form, die direkt in die Datei known_hosts wandert. Für ein gesamtes Subnetz lässt sich der Befehl per Schleife oder über eine Host-Liste vor dem ssh-audit-Lauf einsetzen. Der praktische Nutzen liegt in der Inventarisierung, der Erkennung doppelter Schlüssel über mehrere Hosts und der Vorbereitung von Konfigurationsmanagement-Rollouts.

Sobald ein Ansible- oder Salt-Durchlauf neue SSH-Targets aufnimmt, sammelt ssh-keyscan zunächst alle Schlüssel und HashKnownHosts in der Konfigurationsdatei sshd_config und sorgt anschließend für maskierte Hostnamen in known_hosts.

ssh-keyscan deckt zudem auf, wenn zwei Hosts denselben RSA- oder ED25519-Key vorweisen. Solche Dopplungen treten häufig bei geklonten virtuellen Maschinen auf, die nach dem Klonen nicht regeneriert wurden. Eine Klärung erfolgt über

rm /etc/ssh/ssh_host_*

ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

und einen anschließenden Reload des Daemons. Im Beispielnetzwerk dürfen Gateway 10.0.0.10 und Samba-DC 10.0.5.10 unter keinen Umständen denselben Host-Key vorweisen.

Nmap-NSE-Skripte für tiefer gehende Analysen

Nmap bringt mehrere NSE-Skripte mit, die das Bild abrunden. Das Skript ssh-hostkey gibt MD5- und SHA256-Fingerprints zurück, mit dem Argument ssh_hostkey=full den vollständigen Public Key, mit visual eine ASCII-Art-Darstellung. Über die Postrule erkennt das Skript doppelte Hosts an gemeinsamen Schlüsseln. Der Aufruf

nmap -p22 --script ssh-hostkey --script-args ssh_hostkey=full 10.0.5.10

liefert den vollständigen Schlüssel für eine Verifikation gegen ein bestehendes Asset-Inventar. Für Subnetz-Scans ergänzt sich der Befehl um eine CIDR-Notation:

nmap -p22 --script ssh-hostkey,ssh-auth-methods 10.0.0.0/16

Das Skript ssh-auth-methods listet die akzeptierten Authentifizierungsmethoden eines Servers, darunter publickey, password und gssapi-with-mic. Auf dem Samba-DC mit aktivierter GSSAPI-Konfiguration erscheint gssapi-with-mic in der Liste, was Single Sign-On mit Kerberos-TGT erlaubt. Der Aufruf

nmap -p22 --script ssh-auth-methods --script-args="ssh.user=root" 10.0.5.10

prüft, ob der Server für den Benutzer root noch Authentifizierung anbietet. Eine sichere Konfiguration lehnt root direkt ab und meldet keine verfügbaren Methoden für diesen Account. Das Skript ssh2-enum-algos liefert die vom Server akzeptierten Algorithmen ohne tiefer gehende Bewertung und ergänzt damit die Sicht von ssh-audit. Eine Kombination aus -sV und -sC ergänzt die Versionserkennung und führt die Default-Skripte aus:

nmap -p22 -sV -sC 10.0.5.10

Das Skript ssh-publickey-acceptance prüft, ob ein gegebener Public Key vom Server akzeptiert wird, ohne den vollständigen Login-Vorgang anzustoßen. Der Aufruf liefert Hinweise auf bekannte schwache Schlüssel aus der ssh-badkeys-Datenbank oder auf Debian-PRNG-Schlüssel aus den g0tmi1k-Sammlungen, die durch eine fehlerhafte Zufallsquelle in alten Debian-Paketen vorhersehbar wurden.

Der Mehrwert der Kombination mehrerer Tools

Ein einzelnes Werkzeug greift oft zu kurz und bietet nicht alle Informationen, die für die Absicherung von SSH notwendig sind. Das Tool ssh-audit liefert die Bewertung der Algorithmen und der Policy-Konformität, sieht aber den Banner-Inhalt nur indirekt im Netz und kennt das umliegende Netzwerk nicht. Nmap inventarisiert Hosts, erkennt Versionen, prüft Authentifizierungsmethoden und stößt zusätzliche NSE-Skripte für die SSH-Oberfläche an. Das Tool ssh-keyscan sammelt die öffentlichen Host-Keys schnell und ohne Authentifizierung, ideal für Inventarpflege und Klonerkennung.

Im Audit gegen das Subnetz 10.0.0.0/16 öffnet zuerst ein Nmap-Discovery-Scan die Sicht auf alle Hosts mit offenem Port 22:

nmap -p22 --open -oG ssh_hosts.gnmap 10.0.0.0/16

Aus der Grep-Ausgabe extrahiert ein awk-Einzeiler die Hostliste für ssh-audit:

awk '/Ports: 22/open/{print $2}' ssh_hosts.gnmap > targets.txt

Anschließend läuft

ssh-audit -T targets.txt --threads 32 -j > audit.json

gegen alle erkannten Hosts und schreibt die Ergebnisse als JSON. Ein paralleler Aufruf von

ssh-keyscan -T 5 -t rsa,ecdsa,ed25519 -f targets.txt > keys.txt

sammelt die Host-Keys. Eine Auswertung mit sort und uniq -c zeigt anschließend doppelte Schlüssel über mehrere Hosts hinweg. Im Anschluss prüft eine zweite Nmap-Runde die Authentifizierungsmethoden konkret für privilegierte Konten:

nmap -p22 --script ssh-auth-methods --script-args="ssh.user=root" -iL targets.txt

Server, die für root noch Methoden ausweisen, landen in einer Nachsorgeliste und die Direktive PermitRootLogin no in der sshd_config wird nachgezogen.

Praxis am Samba-DC unter 10.0.5.10

Der Domänencontroller in diesem Beispiel spielt eine spezielle Rolle in diesem Zusammenhang. Samba mit AD-Backend stellt nicht nur SMB- und LDAP-Dienste bereit, sondern integriert auch Kerberos und kann GSSAPI-Authentifizierung an OpenSSH durchreichen. Ein ssh-audit-Scan zeigt zuerst die Algorithmen, ein Nmap-Durchgang mit ssh-auth-methods deckt das Vorhandensein von gssapi-with-mic auf. Der Test einer Kerberos-Anmeldung läuft von einem Linux-Client mit synchronisierter Zeit und gültigem TGT:

ntpdate samba.intern.lab

kinit [email protected]

ssh -o GSSAPIAuthentication=yes [email protected]

Stimmt der SPN nicht, meldet der Server "Server not found in Kerberos database". Eine Korrektur der /etc/krb5.conf und ein Abgleich der DNS-Auflösung lösen das Problem. Im Fall des Samba-DC sollten Administratoren PasswordAuthentication no, PermitRootLogin no und MaxAuthTries 3 setzen, GSSAPI-Authentifizierung jedoch erhalten, sofern Kerberos-Logins gewünscht sind. Der Drop-in-Konfigurationsblock im Verzeichnis /etc/ssh/sshd_config.d/ überschreibt Standardwerte und bleibt Update-resistent gegenüber Paketaktualisierungen.

Auswertung und kontinuierliche Prüfung

Ein einmaliger Audit hat begrenzten Wert. Erst eine wiederkehrende Untersuchung, eingebunden in ein Konfigurationsmanagement oder eine CI-Pipeline, schließt die Lücke nachhaltig. Dabei liefert ssh-audit per JSON strukturierte Ergebnisse, die ein Skript gegen einen Schwellenwert prüft und im Fehlerfall einen Build oder einen Pipeline-Schritt abbricht. Nmap-Ergebnisse landen über -oA in drei Dateiformaten und lassen sich mit Tools zum Beispiel ndiff mit Vorgängerläufen vergleichen.

Die Ausgaben von ssh-keyscan dienen als Goldstandard für known_hosts-Verteilungen über Ansible oder Puppet. Die Kombination der drei Werkzeuge bringt den größten Nutzen, sobald sie Teil einer regelmäßigen Routine wird. Kompromittierte Schlüssel, schleichend in die Konfiguration zurückgekehrte schwache Algorithmen oder neu eingespielte Server mit Standardwerten fallen so im Audit auf, bevor Angreifer sie nutzen.