SSH-Verbindung über HTTPS

SSH über HTTPS übertragen

• Um SSH über HTTPS zu übertragen, müssen sowohl Client als auch Server angepasst werden.
• Im Beispiel für die Client-Konfiguration werden in der Datei ~/.ssh/config ProxyCommand und ServerAliveInterval gesetzt.
• Das verwendete Skript ~/.ssh/https-tunnel.bash erstellt mit socat eine TLS-Verbindung und sendet dabei die Methode CONNECT mit Headern.

Beispiel für die Server-Konfiguration

• In der Apache2-HTTPS-Server-Konfiguration wird proxy_connect_module geladen und mit der Direktive AllowCONNECT die Verwendung der HTTP-Methode CONNECT für bestimmte Ziele erlaubt.
• Auf der Serverseite wird konfiguriert, dass auf dem https-server die Methode CONNECT nur für das einzelne Ziel, den Host ssh-server, verwendet werden kann.

Hintergrund

• Während eines Krankenhausaufenthalts bestand der Wunsch, über das Krankenhaus-WLAN remote zu arbeiten, obwohl dort die meisten Verbindungstypen blockiert sind.
• Das Krankenhausnetzwerk erlaubt nur HTTP- und HTTPS-Verbindungen, während SSH vollständig blockiert ist.
• Daher wurde nach Möglichkeiten gesucht, SSH über HTTP oder HTTPS zu transportieren.

Mögliche Methoden

• Das Projekt sslh hostet SSH- und HTTPS-Protokolle gemeinsam auf einem einzelnen Port und verteilt sie transparent.
• sslh kapselt kein Protokoll in ein anderes ein, sondern leitet mithilfe verschiedener Heuristiken an das tatsächliche Backend weiter.
• Eine weitere Methode ist, mit der Direktive ProxyCommand von openssh das SSH-Protokoll vollständig in ein anderes Protokoll einzubetten.

SSH over HTTP

• Für einen einfachen Versuch mit SSH over HTTP wird Apache2 so konfiguriert, dass die Methode CONNECT für das einzelne Ziel ssh-server:22 erlaubt ist.
• Auf der Client-Seite lässt sich dies leicht mit socat anpassen.
• Mit ServerAliveInterval wird sichergestellt, dass die HTTP-Verbindung auch im Leerlauf nicht getrennt wird.

SSH over HTTPS

• socat unterstützt keine HTTPS-Proxys, wohl aber TLS-Kapselung.
• Eine auf CONNECT basierende Methode lässt sich leicht manuell implementieren.
• Mit dem Skript ~/.ssh/https-tunnel.bash wird Tunneling von SSH über HTTPS umgesetzt.

Fazit

• Die allgegenwärtige Verfügbarkeit von HTTPS ermöglicht es, Daten auch durch stark eingeschränkte Zwischenstationen zu übertragen.
• Die Methode CONNECT ist ein nützlicher Hack, um einen TCP-Payload-Stream in einen TLS-Host-Stream einzupacken.
• ServerAliveInterval wird verwendet, um Verbindungen über untergeordnete Transporte aufrechtzuerhalten, die mit Leerlaufverbindungen nicht gut umgehen können.

Meinung von GN⁺

• Der wichtigste Punkt dieses Artikels ist die kreative Lösung, mit der SSH-Verbindungen auch in eingeschränkten Netzwerkumgebungen möglich werden.
• Die Methode, SSH mit HTTPS zu kombinieren, dürfte besonders für Personen mit Fachwissen in Netzwerksicherheit interessant sein.
• Das Umgehen von Netzwerkeinschränkungen mithilfe von ProxyCommand und ServerAliveInterval bietet nützliche Informationen für Netzwerkadministratoren und Sicherheitsexperten.

[GN⁺]

Hacker-News-Kommentare

• Der niederländische Internetanbieter XS4ALL bot früher SSH-Zugang über Port 80 an. Diese Funktion war nützlich, wenn andere Ports etwa im Hotel-WLAN blockiert waren.
• Die allgegenwärtige Verbreitung von HTTPS ermöglicht es, Daten durch stark eingeschränkte Zwischenstationen zu übertragen. Das ist der Hauptgrund, warum proprietäre VPN-Protokolle, die als SSL-VPN bezeichnet werden, einen Modus implementieren, der den Tunnel über HTTPS startet.
• Man kann SSH auch auf Port 80 oder 443 legen und über einen anderen Host ProxyJump verwenden oder über SOCKS eine weniger eingeschränkte Internetverbindung erhalten. Es ist auch möglich, DNS über TLS über eine SSH-Verbindung weiterzuleiten.
• Ein Unternehmen namens Adaptive baut derzeit eine Datensicherheitsinfrastruktur auf, die über HTTP3 SSH und verschiedene andere Protokolle bereitstellt. Dadurch können Nutzer über externe Ports eine Verbindung zu Datenbanken, Servern und anderen Ressourcen herstellen.
• Tatsächlich lassen sich die meisten Firewalls umgehen, indem openssh einfach auf Port 443 lauscht.
• Es ist interessant, die CONNECT-Methode eher wie einen Reverse-Proxy als wie einen Forward-Proxy zu betrachten. Allerdings reicht CONNECT allein nicht aus, daher wird SSH über WebSockets verwendet, um Unternehmens-Proxys zu umgehen.
• Die Häufigkeit von Beiträgen über „neue“ Lösungen ist unerquicklich. Diese Ideen sind nicht neu, und viele Menschen kennen sie bereits.
• Es wäre gut, wenn ein SSH-ähnliches Identitätsmanagementsystem in Browser eingebaut wäre. Als ich zum ersten Mal von dem Vorschlag für die Public-Key-HTTP-Authentifizierung namens hobo las, war ich begeistert, stellte dann aber fest, dass es weder eine Server-Implementierung noch eine Client-Implementierung im Browser gibt.
• Vor etwa 20 Jahren nutzte ich das Werkzeug corkscrew, um durch Unternehmens-Firewalls zu kommen. Eine unabhängige Implementierung und Beschreibung dieses Werkzeugs ist beeindruckend.
• Tunneling über HTTP2 ist eine hervorragende Wahl. Es gibt gRPC, ein auf HTTP2 aufgebautes RPC-Protokoll. HTTP2 eignet sich hervorragend dafür, mehrere Datenstrukturen gleichzeitig über eine TCP-Verbindung zu senden und zu empfangen. Allerdings muss man HTTP3 möglicherweise gar nicht verwenden, da QUIC selbst bereits Multiplexing bietet.