☰

Unterstützt SSH *echte* Pre-Shared Keys?

tag-icon • tag-icon ssh security encryption
Unterstützt SSH *echte* Pre-Shared Keys?

Es ist allgemein bekannt, dass sshddie Ausführung auf einem öffentlich zugänglichen Rechner ein köstlicher Angriffsvektor ist und daher so gut wie möglich geschützt werden sollte. Abgesehen von offensichtlichen Ratschlägen wie „set PermitRootLoginto no“ und „switch to pubkey authentication“ habe ich folgende Methoden gefunden, um den Zugriff auf meinen Rechner für Script-Kiddies mit nmap: einzuschränken.

  • Ändern Sie den Port auf etwas anderes als 22. Hilft gegenüber dem oben genannten nicht wirklich nmap.
  • Lassen Sie Port 22 offen, aber lassen Sie einfach alles fallen, was dort ankommt, und akzeptieren Sie stattdessen SSH-Verbindungen von einem anderen Port mitdiese Krücke. Besser als die vorherige Methode, aber immer noch nicht mehr als ein Hindernis.
  • Port-Knocking einrichten. Umständlich undTrotzdemnicht ganz sicher, da der „klopfende“ Verkehr abgefangen werden kann.

Wenn ich ein System für den Fernzugriff auf meinen Computer entwerfen würde, würde es folgendermaßen aussehen:

  1. Generieren Sie ein zufälliges Geheimnis.
  2. Kopieren Sie es manuell auf beide Maschinen, die verbunden werden sollen (für maximale Speicherdauer kann dies sogar mit einem Flash-Laufwerk erfolgen).
  3. Derallererstes Paket(d. h. die SSH-Handshake-Initiierung), die der Client-Rechner an den Server sendet, istbereitsmit diesem Geheimnis verschlüsselt.
  4. Wenn der Server ein Paket empfängt, das nicht korrekt mit diesem Geheimnis verschlüsselt ist, schließt er einfach stillschweigend die TCP-Verbindung.

Das Ergebnis ist, dass esphysikalisch unmöglichfür einen Angreifer, überhaupt herauszufinden, dass ein SSH-Dienst auf dem Server läuft. In meinem KopfkanonDasist genau die Bedeutung von „Pre-Shared Key“.

Wenn ich stattdessen versuche, nach „SSH mit vorinstalliertem Schlüssel“ zu suchen, werden mir nur Links zu Artikeln angezeigt, die die Migration von PasswordAuthenticationnach beschreiben PubkeyAuthentication.

Antwort1

Nein, das tut es nicht. Auf Protokollebene beginnt jede Standard-SSHv2-Verbindung immer mit 1) dem Protokollversions-„Banner“ in einfachem ASCII, 2) einem unverschlüsselten Paket, das alle unterstützten Chiffren und Schlüsselaustauschmethoden auflistet.

Ab Schritt 3könnteImplementieren Sie eine benutzerdefinierte Schlüsselaustauschmethode, die einen PSK beinhaltet (idealerweiseZusätzlichzum üblichen dynamischen DH-Schlüsselaustausch), aber dazu wären ein angepasster SSHD-Daemon sowie angepasste Clients erforderlich. Eine solche Funktion gibt es derzeit weder in OpenSSH, noch in PuTTY, noch in Bitvise WinSSHD, noch in einer anderen SSHv2-Implementierung, mit der ich bisher herumgespielt habe.

Die einfachste Alternative wäre die Verwendung eines VPN-Systems, da diese häufig PSKs unterstützen (aber häufiger als HMAC-Schlüssel zum Schutz des anfänglichen Schlüsselaustauschs – nicht als AES-Schlüssel zum Verschlüsseln des eigentlichen Datenkanals, da dadurch die Funktion „Forward Secrecy“ verloren gehen würde). Sobald Sie einen VPN-Dienst ausführen, können Sie direkte SSH-Verbindungen einfach vollständig deaktivieren: Niemand kann einen SSHD entdecken, der buchstäblich nicht mehr zuhört.

Beispielsweise unterstützen sowohl WireGuard als auch OpenVPN die Verwendung eines vorab freigegebenen MAC-Schlüssels zur Authentifizierung aller Verbindungsversuche. Da beide UDP für die anfängliche Aushandlung verwenden, reagieren sie einfach nichtüberhauptzu nicht überprüfbaren Paketen, wodurch der Dienst nicht erkennbar wird. (Obwohl ich glaube, dass WireGuard dies bereits auch ohne PSK-Modus tut ...) Beachten Sie, dass OpenVPN diese Funktion „tls-auth“-Modus nennt – verwechseln Sie sie nicht mit dem „Static-Key“-Modus.

Es wäre auch möglich, hier IPsec AH zu verwenden – wenn Sie nur einen vollständig statischen Authentifizierungsschlüssel benötigen, wäre es möglich, an beiden Enden manuell einen SA zu konfigurieren, ohne dass überhaupt ein dynamischer IKE-Handshake erforderlich wäre, nur mit einem ip xfrmBefehl. Aber das kann lästig werden.

Als weitere Alternative unterstützen einige BetriebssystemeTCP-EbenePre-Shared-Key-Authentifizierung mit entweder TCP-MD5 (RFC1321) oder TCP-AO (RFC5925). Dies ließe sich leicht in SSH-Software hacken, da nur ein einziger Sockopt erforderlich ist, obwohl dies wieder in den Bereich benutzerdefinierter Clients vordringt. Außerdem ist die Unterstützung auf Betriebssystemebene dürftig – obwohl TCP-MD5 noch unterstützt wird, da Benutzer es mit BGP verwenden möchten, ist die Unterstützung für TCP-AO möglicherweise praktisch nicht vorhanden.

verwandte Informationen