SSH3 – eine schnellere und funktionsreichere Secure Shell mit HTTP/3

 (github.com/francoismichel)
8 Punkte von GN⁺ 2025-09-28 | 1 Kommentare | Auf WhatsApp teilen
  • SSH3 ist ein Sicherheits-Shell-Protokoll der nächsten Generation, das auf HTTP/3 aufsetzt und die Geschwindigkeit beim Sitzungsaufbau im Vergleich zu traditionellem SSHv2 deutlich verbessert
  • Über QUIC und TLS 1.3 wird ein sicherer Kanal aufgebaut; zudem werden moderne Authentifizierungssysteme wie OAuth 2.0 und OpenID Connect unterstützt
  • Server können hinter einem geheimen Pfad verborgen werden und sind dadurch widerstandsfähiger gegen Angriffe wie Port-Scanning; außerdem bietet SSH3 neue Funktionen wie UDP-Port-Forwarding und QUIC-Multipath
  • Mehrere Kernfunktionen von OpenSSH wurden bereits übernommen, das Projekt befindet sich jedoch aktuell noch in einem experimentellen Stadium, weshalb ein Einsatz in produktiven Umgebungen nicht empfohlen wird
  • Da viele der Ansicht sind, dass der Name SSH3 nicht passend ist, wurde der Standardisierungsentwurf in „Remote Terminals over HTTP/3“ umbenannt, und eine Namensänderung ist im Gange

Überblick über das SSH3-Projekt und seine Bedeutung

  • SSH3 ist eine Open-Source-Lösung, die das bestehende SSH-Protokoll für HTTP/3 und moderne Webtechnologien neu entwirft
    • Die Semantik des bestehenden SSH-Verbindungsprotokolls (RFC4254) wird über HTTP/3 Extended CONNECT und einen Kanal aus QUIC+TLS 1.3 neu aufgebaut
  • Vorgeschlagen wurde es als IETF-Internet-Draft draft-michel-remote-terminal-http3; es verkürzt die Zeit für den Sitzungsaufbau deutlich und bietet verschiedene Vorteile wie die Erweiterung moderner Authentifizierungsverfahren
  • Im Vergleich zu anderen SSH-Implementierungen zeichnen es innovative Ideen wie die Nutzung von QUIC und verborgene Serverkonfigurationen aus

Wichtige Funktionen und Merkmale

  • Schneller Sitzungsaufbau
    • Während eine klassische SSHv2-Verbindung im Durchschnitt 5 bis 7 Netzwerk-Roundtrips benötigt, kommt SSH3 mit nur 3 Roundtrips aus und reduziert dadurch die vom Nutzer wahrgenommene Wartezeit erheblich
    • Die Latenz bei Tastatureingaben bleibt auf dem bisherigen Niveau
  • Verbesserte Sicherheit
    • Basierend auf TLS 1.3, QUIC und HTTP-Authentifizierung nutzt es bewährte Sicherheitsprotokolle, die bereits im E-Commerce und Online-Banking eingesetzt werden
    • Unterstützt öffentliche Schlüssel auf Basis von RSA und EdDSA/ed25519 sowie verschiedene Authentifizierungsmethoden wie OAuth 2.0 und OpenID Connect
    • Auch die Anmeldung mit Google-, Microsoft- und Github-Konten ist möglich
  • Funktion zum Verbergen des Servers
    • Der Server kann hinter einer bestimmten geheimen URL liegen, z. B. https://192.0.2.0:443/M3MzkxYWMx...; er antwortet nur, wenn an diese URL eine Authentifizierungsanfrage gesendet wird
    • Auf alle anderen Anfragen wird mit 404 Not Found geantwortet, sodass Angreifer oder Crawler im Internet die Existenz des Servers nicht erkennen können
    • Der geheime Pfad ersetzt jedoch keine Authentifizierung; daher wird ausdrücklich empfohlen, zusätzlich eigene Authentifizierungsmechanismen wie öffentliche Schlüssel, Passwort oder OIDC zu verwenden
  • Experimentelles Projekt in aktiver Entwicklung
    • Die Struktur erfordert eine belastbare Überprüfung der Sicherheit, und ein Einsatz auf produktiven Servern wird nicht empfohlen
    • Derzeit wird in Testumgebungen oder geschlossenen Netzwerken Community-Feedback gesammelt
  • OpenSSH-Kompatibilität und zusätzliche Funktionen
    • Parsing von ~/.ssh/authorized_keys und known_hosts, Integration mit ssh-agent, TCP-/UDP-Port-Forwarding und Unterstützung für Proxy Jump
    • Durch UDP-Forwarding werden Zugriffswege zu UDP-basierten Servern wie DNS-, RTP- und QUIC-Diensten bereitgestellt; verwendet wird ein QUIC Datagram-Pfad
    • X.509-Zertifikate ermöglichen eine Serverauthentifizierung auf HTTPS-Niveau
    • Keyless-Authentifizierung: Mit OpenID Connect ist ein Zugriff ohne Kopieren öffentlicher Schlüssel möglich, nur mit Unternehmens-SSO oder externen Konten wie Google oder Github

Fazit

  • SSH3 ist ein experimentelles Open-Source-Projekt, das die SSH-Umgebung durch moderne Netzwerkprotokolle und Authentifizierung weiterentwickelt
  • Es verbessert Geschwindigkeit, Flexibilität und Sicherheit deutlich, dennoch ist vor einer ausreichenden Prüfung Vorsicht beim produktiven Einsatz geboten
  • Es bietet eine OpenSSH-ähnliche Nutzererfahrung und zugleich zahlreiche neue Funktionen
  • Mit einer fundierten Sicherheitsbewertung und aktiver Community-Beteiligung hat es das Potenzial, sich als SSH der nächsten Generation zu etablieren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-09-28
Hacker-News-Kommentare
  • Der Name ssh3 gefiel mir wirklich nicht, daher fand ich es gut, dass ganz oben im Repo steht: „SSH3 wird umbenannt. Im Moment läuft es noch als SSH Connection Protocol (RFC4254) über HTTP/3 Extended CONNECT, aber es sind so viele Änderungen nötig und es unterscheidet sich so stark von bestehendem SSH, dass es nicht einfach integriert werden kann. Der Entwurf der Spezifikation wurde bereits in ‚Remote Terminals over HTTP/3‘ umbenannt, und wir brauchen Zeit, um über einen besseren dauerhaften Namen nachzudenken.“
    • So ein Name wirkt, als hätte jemand ein Repo mit dem Titel „Windows 12“ oder „Linux 7“ erstellt – irgendwie unpassend.
    • Als Alternative zu SSH3 wurde so etwas wie Secure Hypertext Interactive TTY vorgeschlagen.
    • Ich habe über SSH/3 nachgedacht (im Sinne von SSH + HTTP/3).
    • Dieser Thread ist wirklich ein Meisterwerk des ausgewachsenen „bike-shedding“.
    • Ich dachte an so etwas wie SSH2/3, weil es größtenteils SSH2 ist, nur eben über HTTP/3 läuft.
  • SSH ist langsam, und meiner Erfahrung nach liegt der größte Flaschenhals beim Session-Setup. Ob wegen PAM oder wegen OpenBSD-Richtlinien: Jedes Mal ist dieser Schritt ernsthaft langsam, egal ob man eine SSH-Verbindung wiederverwendet oder neu aufbaut. Für lange Sitzungen ist das okay, aber selbst für einen einzelnen simplen Befehl gibt es jedes Mal Overhead. Deshalb war ich auch mit der Ansible-Performance nicht zufrieden und habe mir schließlich selbst ein kleines Mini-Ansible für Remote-Kommandos ohne Session-Overhead gebaut.
  • Ich war skeptisch bei der Frage „Ist das wirklich schneller als traditionelles SSH?“, aber laut README ist nur die Verbindungsherstellung schneller, während die tatsächliche Geschwindigkeit nach dem Verbindungsaufbau gleich bleibt. Das ist als Verbesserung schon plausibel.
    • In diesem Sinn ist es tatsächlich nicht schneller. Wenn man bei einer einzelnen SSH-Verbindung mehrere Ports für Traffic Forwarding nutzt, kann Head-of-Line-Blocking auftreten, und QUIC/HTTP3 kann dieses Problem lösen.
    • Ich würde wetten, dass dieses Protokoll auf Verbindungen mit hoher Latenz viel schneller als SSH sein wird. Weil es auf UDP basiert, kann es große Datenmengen fortlaufend senden, ohne auf ACKs zu warten. Deshalb erwarte ich deutliche Geschwindigkeitsgewinne beim scp großer Dateien rund um den Globus.
    • Über VPN könnte es wirklich schneller sein, weil die Falle „TCP in TCP“ wegfällt.
    • Einer der Hauptvorteile von HTTP/3 bzw. QUIC insgesamt sind weniger Roundtrips gegenüber früher, was genau dazu passt, dass der Verbindungsaufbau schneller wird.
  • Die Erklärung lautete: „SSHv2 benötigt für die Session-Initialisierung etwa 5–7 Roundtrips, SSH3 nur 3. Während der eigentlichen Sitzung bleibt die Eingabelatenz (Tastendruck bis Reaktion) gleich.“ Aus Nutzersicht hat mich die Verbindungsgeschwindigkeit nie besonders gestört, deshalb spricht mich das nicht sehr an. SSH hat außerdem eine im harten Einsatz bewährte Zuverlässigkeit, und selbst wenn so ein neues Tool produktionsreif wäre, wäre das Vertrauen darin mit erheblichem Risiko verbunden.
    • UDP-Tunnel sind die eigentliche Kernfunktion, viel leichter als WireGuard, und es gibt auch Dinge wie OpenID-Authentifizierung.
    • „Verbindungsgeschwindigkeit“ hat mich immer zumindest ein wenig gestört. Besonders schade fand ich, wenn man remote einfach nur schnell einen Befehl ausführen wollte.
    • In ssh3 wurde Head-of-Line-Blocking vermutlich gelöst, daher dürfte es schneller sein, wenn mehrere Ports oder Verbindungen über eine physische Verbindung multiplexed werden.
    • Wenn du eine flüssige User Experience willst, empfehle ich Mosh.
  • Ich weiß nicht, warum es sich so traurig anfühlt, wenn alle Application-Layer-Protokolle von HTTP absorbiert werden.
    • Wenn das wirklich die Richtung ist, wäre das tatsächlich traurig. Das typische HTTP-Modell ist in den meisten Fällen zu einschränkend und zugleich zu komplex. Aber HTTP/2 oder QUIC (der Transport von HTTP/3) sind so universell, dass schon die Bezeichnung HTTP selbst an Bedeutung verliert. Zumindest QUIC wird ziemlich klar als TCP-Ersatz positioniert.
    • Eigentlich finde ich es sogar positiv, wenn so alle Protokolle standardisiert werden, weil Traffic Shaping, Zensur und Ähnliches dadurch schwieriger werden. Am Ende ist Traffic entweder HTTP oder ein zufälliger Bytestrom, also unauffällig, und damit schwerer zu überwachen oder zu blockieren. Wenn man ein neues Protokoll baut, ist es – sofern der ISP dafür nichts speziell bevorzugt – am praktikabelsten, es als HTTP zu tarnen, ohne langsamer zu werden.
    • Dieses Phänomen ist auch die Folge davon, dass Enterprise-Security-Teams ständig alles blockieren oder dazwischenfunken wollen. Ja, ihr Teams mit Zscaler oder TLS-MitM-Modus seid gemeint.
    • Solche Sperren sieht man auch in Flughafen-WLANs oder Hotels auf der ganzen Welt. Dass man zum Beispiel mit Apple Mail keine Mails senden kann, liegt daran, dass aus Unternehmensrichtlinien Port 25 blockiert wird. Unter dem Vorwand der Spam-Bekämpfung werden dann auch 143, 587, 993 usw. dichtgemacht, sodass am Ende nur 80 und 443 durchkommen. Hoffentlich bringt IPv6 etwas Besserung. Und Dinge wie die EU-Initiative ChatControl sollten aufhören. Man sollte wirklich mal auf Leute hören, die tatsächlich etwas von IT verstehen.
    • Ich kann auch nachvollziehen, dass man wegen der immer komplexeren Verbindungsinitialisierung am Ende auf Best Practices auf Basis battle-tested Protokolle zurückgreifen will. Aber es wirkt trotzdem seltsam, weiterhin von HTTP zu sprechen, wenn die eigentliche Übertragung längst kein Hypertext mehr ist.
  • Es ist cool, dass sich die SSH-Funktionalität weiterentwickelt, aber wenn man es ohnehin fast neu baut, hätte ich mir auch experimentellere neue Features gewünscht. Zum Beispiel Komfortfunktionen wie bei Mosh für „Roaming / vorübergehende Netzinstabilität“ wären schön https://mosh.org/
    • Der Vorteil von Mosh ist, dass die Reaktion auf Tastenanschläge extrem schnell ist und es sich fast so anfühlt, als würde man direkt in einer lokalen Shell arbeiten. Ich frage mich, ob SSH3 da überhaupt Verbesserungen bringt. QUIC wird manches etwas abfedern, aber das ist nochmal etwas anderes als Mosh.
    • So wie ich es verstehe, sind Connection Migration und Multipath grundlegende Eigenschaften von QUIC. Beim Unterschied zwischen Roaming-Funktion und „eingebautem tmux“ bin ich mir aber nicht sicher, ob echter Mehrwert erst dann entsteht, wenn das direkt ins System integriert ist.
  • Ich frage mich, warum Menschen so auf kurze Namen und Akronyme fixiert sind – ich finde das wirklich nicht gut. Heute können Befehle ruhig länger sein, solange sie technisch möglichst klar sind. Man sollte standardmäßig den ausgeschriebenen Namen verwenden, und Abkürzungen können dann von einzelnen Systemadministratoren oder Distributionen gekürzt werden. Den Leuten sollte man die vollständigen Namen beibringen. Zum Beispiel wäre Set-Location besser als cd, und ein Name wie remote-terminals-over-http3 wäre besser als ssh3.
  • Der letzte Commit ist ein Jahr her – weiß jemand etwas über den aktuellen Stand des Projekts?
  • Ich wurde neugierig auf die Projektpläne. Weder bei Releases noch bei GitHub-Aktivitäten gab es seit über einem Jahr Neuigkeiten. Da das Ganze mit einer wissenschaftlichen Arbeit begann, könnte es sein, dass im Hintergrund weiter an Forschung oder anderen Nebenarbeiten gearbeitet wurde.
    • Danke für den Hinweis auf diesen Punkt. Persönlich würde ich sagen, dass dieses Projekt inzwischen tot ist. Mit rund 239 Commits ist es faktisch nur ein Proof of Concept und noch nichts, das man ernsthaft einsetzen würde. Im Gegensatz dazu ist bei OpenBSD bzw. OpenSSH weiterhin extrem viel Aktivität zu sehen, daher scheint ein wirklicher Ersatz noch lange nicht in Sicht https://github.com/openbsd/src/commits/master/
  • Die Projektidee ist gut. Besonders spannend wäre es, wenn sich das über einen normalen H3-Proxy proxien ließe. Wenn dazu noch Multipath/Migration und die TCP-bedingten Blocking-Probleme gelöst werden, wäre das bereits ein enormer Fortschritt.