SSH ist seit Jahrzehnten das Werkzeug, wenn es um den geschützten Zugriff auf entfernte Systeme geht. Administratoren öffnen damit Konsolen, Entwickler übertragen Quellcode, Automatisierungen laufen auf dieser Basis. SSH gehört längst zum Standardrepertoire der IT, doch die Welt drumherum hat sich verschoben. Heute laufen Verbindungen durch vielschichtige Firewalls, landen in verteilten Cloud-Architekturen oder bewegen sich in streng kontrollierten Zero-Trust-Umgebungen. Solche Szenarien waren in den Anfangsjahren des Protokolls schlicht kein Thema. Mit SSH3 liegt nun ein Konzept auf dem Tisch, das diese veränderten Rahmenbedingungen berücksichtigt.

Fundament auf HTTP/3 und QUIC
Der entscheidende Unterschied zum klassischen SSH liegt im Transport. Statt eine eigene Schicht zu nutzen, baut SSH3 auf HTTP/3 auf. Darunter arbeitet QUIC, ergänzt um TLS 1.3. Diese Kombination wurde ursprünglich für den Webverkehr entwickelt und bringt Eigenschaften mit, die sich auch für Remote-Zugriffe eignen. QUIC ermöglicht Verbindungen mit sehr kurzem Handshake, was den Start einer Sitzung beschleunigt. Zudem lassen sich mehrere Datenströme parallel innerhalb einer Verbindung betreiben, was gerade bei komplexeren Workflows Vorteile bringt.
Geschwindigkeit im Alltag
Wer viele SSH-Sessions am Tag startet, bemerkt die Unterschiede schnell. Während man bei klassischem SSH die kurze Pause beim Verbindungsaufbau gewohnt ist, öffnet SSH3 Sitzungen nahezu verzögerungsfrei. Besonders bei automatisierten Prozessen, die ständig neue Sessions anlegen, summiert sich dieser Effekt. Statt jedes Mal erneut eine komplette Aushandlung zu durchlaufen, profitiert SSH3 vom optimierten Ablauf des QUIC-Protokolls.
Neue Formen der Authentifizierung
Ein weiterer Unterschied zeigt sich bei der Anmeldung. Klassisches SSH arbeitet mit Passwörtern oder Schlüsselpaaren, die lokal hinterlegt werden. SSH3 erlaubt zusätzlich den Einsatz von OAuth 2.0 und OpenID Connect. Das sind Standards, die in modernen Unternehmensumgebungen längst etabliert sind. Dadurch lassen sich zentrale Identitätsdienste einbinden, ohne zusätzliche Schlüsselverwaltung. Für größere Organisationen bedeutet das eine nahtlose Integration in bestehende Systeme, während Nutzer von einem vertrauten Login-Verfahren profitieren.
Sicherheit durch Tarnung
SSH ist in seiner klassischen Form für Angreifer leicht zu entdecken. Ein Portscan reicht aus, um offene Zugänge sichtbar zu machen. SSH3 entzieht sich dieser Methode, weil es über die üblichen HTTPS-Ports läuft. Für Außenstehende sieht der Datenverkehr aus wie gewöhnlicher Webtraffic. Ein gezieltes Auffinden von Zugängen wird damit erheblich schwieriger. Die Verschlüsselung erfolgt dabei über TLS 1.3, womit die aktuellen Standards der Kryptografie umgesetzt sind.
Do not deploy the SSH3 server on your production servers for now
Given the current prototype state, we advise testing SSH3 in sandboxed environments or private networks. Be aware that making experimental servers directly Internet-accessible could introduce risk before thorough security vetting.
—‐—————————————
Prototype und weit weg von fertig.
Somit noch nicht Alltagstauglich
Großer Wurf? Fehlanzeige. QUIC arbeitet über UDP, das in vielen Unternehmensumgebungen nicht gerne gesehen ist oder gar grundsätzlich gesperrt ist. HTTP is unnötiger Overhead und dann noch das Cloud Gefummel mit OAuth und OpenID. Da bleibe ich lieber beim herkömmlichen SSH. Schnelles Öffnen einer Session ist nicht das Problem, das hat noch nie irgendwie Probleme gemacht. Hauptsache irgendwas verschlimmbessern, statt vorhandens härten und fehlerfrei machen.
>SSH3 is probably going to change its name. It is still the SSH Connection Protocol (RFC4254) running on top of HTTP/3 Extended connect
>
Also ein altes Protokoll + ein Müllprotokoll (HTTP/3). Warum ist HTTP/3 und QUIC Müll? Kaum Leistungssteigerung gegenüber HTTP/2 SPDY, aber benötigt mehr als einen Port. HTTP/3 braucht zusätzlich viele UDP-Ports. Es macht nichts originelles. Gerade bei SSH benötigt man genau nur eine Verbindung.
HTTP/3 ist für Firmen die giga scaling brauchen um Millionen Kunden hinter Load Balancern mit Webseiten und Webinhalten, Resourcen hinter CDNs zu versorgen. HTTP/3 hat eine Existenzberechtigung und einen Sinn, der mit Verlaub mit SSH gar nicht überlappt.
Weniger Round trips? Vollkommen irrelevant! Außer ich muss millionen verbindungen starten. Die Round trips verursachen keine latenz wenn die Leitung steht.
Weiter geht es: MOSH, das löst ein reales Problem; stabile SSH in high package loss environments wie LTE/Mobile-Daten-Verbindungen.
https://en.wikipedia.org/wiki/Mosh_(software)?useskin=vector
Mir tut es wirklich leid über das neue Protokoll herzuziehen. Es ist nicht gegen die Autoren, weder hier noch dort. Aber wie E. Bassi von GNOME sagen würde: „Use case?“ Das ist bis dato Bloat. Man darf meine Argumentation gerne angreifen. Meine Kritik ist rein technischer Natur. Trotzdem gutes Themenfeld für Artikel. Ich bin halt eher ein MOSH-User.