SSH: Fernzugriff absichern

SSH-1, das ursprüngliche Secure-Shell-Protokoll, enthielt einen grundlegenden Designfehler, durch den ein aktiver Angreifer beliebige Daten unbemerkt in eine verschlüsselte Sitzung einschleusen konnte. SSH-2, ein vollständiger Protokollneuentwurf, der 2006 als RFC 4251-4254 veröffentlicht wurde, behob diese Schwachstellen durch separate Protokolle für Transport-, Authentifizierungs- und Verbindungsschicht sowie durch eine stärkere Integritätsprüfung mit HMAC. SSH-1 ist veraltet, und kein moderner Server sollte es aktivieren.

Das Protokoll der SSH-Transportschicht übernimmt den anfänglichen Schlüsselaustausch und richtet einen verschlüsselten, integritätsgeschützten Kanal ein. Es handelt Algorithmen für den Schlüsselaustausch (typischerweise ECDH), die Host-Authentifizierung (typischerweise Ed25519 oder RSA), die symmetrische Verschlüsselung (typischerweise AES-256-CTR oder ChaCha20-Poly1305) und den MAC (typischerweise HMAC-SHA2-256) aus. Jedes nachfolgende Paket wird mit den ausgehandelten Algorithmen sowohl verschlüsselt als auch auf Integrität geprüft.

Sobald die Transportschicht gesichert ist, handelt die Benutzerauthentifizierungsschicht aus, wie der Benutzer dem Server seine Identität nachweist. Drei verbreitete Methoden sind Passwort (der Benutzer gibt ein Passwort ein, das verschlüsselt über die Transportschicht gesendet wird), öffentlicher Schlüssel (der Benutzer weist nach, dass er den privaten Schlüssel besitzt, der zu einem autorisierten öffentlichen Schlüssel auf dem Server gehört) und GSSAPI (Kerberos-Integration für Single Sign-On in Unternehmensumgebungen).

Die SSH-Verbindungsschicht multiplexiert mehrere logische Kanäle über die eine verschlüsselte Transportverbindung. Eine typische SSH-Sitzung verfügt über einen Kanal für die interaktive Shell. Zusätzliche Kanäle unterstützen Portweiterleitung, X11-Weiterleitung und die SFTP-Dateiübertragung; alle nutzen dieselbe authentifizierte und verschlüsselte Verbindung. Mit Kanalanforderungen kann der Client ein Pseudo-Terminal anfordern, Umgebungsvariablen setzen oder einen bestimmten Befehl ausführen.

Beim ersten Verbindungsaufbau zu einem SSH-Server erhält der Client den Hostschlüssel des Servers und muss entscheiden, ob er ihm vertraut. Die Standardrichtlinie ist Trust On First Use (TOFU): Der Benutzer wird aufgefordert, den Fingerabdruck des Schlüssels zu überprüfen (typischerweise als Hash wie SHA256:... angezeigt); wenn er akzeptiert wird, wird er in der Datei known_hosts gespeichert. Bei nachfolgenden Verbindungen wird der gespeicherte Schlüssel mit dem vom Server präsentierten Schlüssel verglichen, und bei einer Abweichung wird eindringlich vor möglichen Man-in-the-Middle-Angriffen gewarnt.

Die Datei known_hosts unter ~/.ssh/known_hosts verwaltet eine Datenbank der Hostschlüssel von Servern, indexiert nach Hostnamen und IP-Adressen. Jeder Eintrag verknüpft die Adresse eines Servers mit seinem öffentlichen Schlüssel. Wenn sich der Schlüssel eines Servers ändert, etwa weil der Server neu installiert wurde oder weil ein Angreifer ihn imitiert, verweigert SSH die Verbindung und zeigt eine Warnung an. Administratoren verwenden eine zertifikatsbasierte Hostauthentifizierung, um TOFU-Vertrauensentscheidungen in großem Maßstab zu vermeiden.

Bei der Authentifizierung mit öffentlichen Schlüsseln wird der öffentliche Schlüssel des Benutzers in ~/.ssh/authorized_keys auf dem Server gespeichert. Wenn der Benutzer eine Verbindung herstellt, sendet der Server eine mit dem öffentlichen Schlüssel verschlüsselte Herausforderung; nur der Besitzer des passenden privaten Schlüssels kann korrekt darauf antworten und so seine Identität nachweisen, ohne den privaten Schlüssel oder ein Passwort zu übertragen. Dies ist sicherer als Passwörter, weil private Schlüssel niemals über das Netzwerk gesendet werden und nicht durch Phishing erbeutet werden können.

Drei Familien von SSH-Schlüsselalgorithmen sind weit verbreitet. RSA-Schlüssel mit 3072 oder 4096 Bit sind mit allen Servern kompatibel. ECDSA mit der NIST-P-256-Kurve ist bei gleichwertiger Sicherheit schneller als RSA, aber die Sicherheitsparameter von P-256 wurden kritisch hinterfragt. Ed25519, das auf dem Edwards-Kurven-Digital-Signaturalgorithmus basiert, ist die moderne Empfehlung: schnelle, kleine 256-Bit-Schlüssel, starke Sicherheitseigenschaften und keine speziellen Bedenken hinsichtlich der Parameter.

Tatu Ylönen, ein finnischer Forscher an der Technischen Universität Helsinki, entwickelte SSH 1995, nachdem ein Angriff zum Abhören von Passwörtern in seinem Universitätsnetzwerk Hunderte Zugangsdaten offengelegt hatte. Er wählte Port 22, weil dieser zwischen telnet (23) und ftp (21) lag. SSH ersetzte beide unsicheren Protokolle. Ylönen gründete SSH Communications Security und veröffentlichte SSH-2 später als offenen Standard über die IETF. OpenSSH, die vorherrschende freie Implementierung, wurde 1999 vom OpenBSD-Projekt entwickelt.

Der SSH-Agent ist ein Hintergrundprozess, der entschlüsselte private Schlüssel im Speicher hält und dadurch Single Sign-On bei mehreren Servern ermöglicht, ohne die Passphrase erneut einzugeben. Die Agent-Weiterleitung (-A flag) erweitert dies, indem die Agent-Verbindung an entfernte Server weitergeleitet wird, wodurch ein Zugriff über einen Zwischenhop auf interne Server möglich wird. Die Agent-Weiterleitung stellt jedoch ein Sicherheitsrisiko dar: Ein kompromittierter entfernter Server kann den weitergeleiteten Agenten verwenden, um sich bei anderen Servern als Sie zu authentifizieren. Verwenden Sie ProxyJump statt der Agent-Weiterleitung.

Eine sichere SSH-Konfiguration umfasst das Deaktivieren der Root-Anmeldung (PermitRootLogin no), das Deaktivieren der Passwortauthentifizierung (PasswordAuthentication no) zugunsten einer ausschließlichen Authentifizierung mit öffentlichen Schlüsseln, die Verwendung von Ed25519-Hostschlüsseln, die Aktivierung ausschließlich des SSH-2-Protokolls, die Konfiguration von Zeitlimits für inaktive Sitzungen, die Einschränkung der zugelassenen Benutzer mit AllowUsers oder AllowGroups sowie die Änderung des Standardports als Maßnahme der Verschleierung, um das Rauschen automatisierter Scans zu reduzieren. Fail2ban oder ähnliche Tools blockieren IPs mit wiederholt fehlgeschlagenen Anmeldeversuchen.

Warum gilt die SSH-Authentifizierung mit öffentlichen Schlüsseln als sicherer als die Passwortauthentifizierung?

SSH-2 ersetzte das fehlerhafte SSH-1 durch separate Transport-, Authentifizierungs- und Verbindungsschichten. Die Transportschicht handelt Verschlüsselung und Integrität aus. Die Benutzerauthentifizierung unterstützt Passwörter, öffentliche Schlüssel und GSSAPI. Die Überprüfung von Hostschlüsseln verwendet TOFU und known_hosts. Ed25519 ist der empfohlene Schlüsselalgorithmus. Die Agent-Weiterleitung stellt ein Sicherheitsrisiko dar; verwenden Sie stattdessen ProxyJump. Zur Absicherung gehören das Deaktivieren der Root-Anmeldung und der Passwortauthentifizierung.