francoismichel/ssh3Schnelles, sicheres Shell-Protokoll, das auf HTTP/3, QUIC und TLS 1.3 aufbaut. Unterstützt OAuth2, OpenID Connect und klassische SSH-Authentifizierung mit UDP-Portweiterleitung und versteckten Serverfunktionen.
[!NOTE] SSH3 wird wahrscheinlich seinen Namen ändern. Es ist immer noch das SSH-Verbindungsprotokoll (RFC4254), das auf HTTP/3 Extended Connect läuft, aber die erforderlichen Änderungen sind umfangreich und zu weit entfernt von der Philosophie gängiger SSH-Implementierungen, um für eine Integration in Betracht gezogen zu werden. Der Spezifikationsentwurf wurde bereits umbenannt ("Remote Terminals over HTTP/3"), aber wir brauchen etwas Zeit, um einen schönen, dauerhaften Namen zu finden.
SSH3 ist eine vollständige Überarbeitung des SSH-Protokolls, die dessen Semantik auf die HTTP-Mechanismen abbildet. Es entstammt unserer Forschungsarbeit und wir (Forscher) haben es kürzlich als Internet-Draft (draft-michel-remote-terminal-http3-00) vorgeschlagen.
Kurz gesagt, SSH3 verwendet QUIC+TLS1.3 für den Aufbau des sicheren Kanals und die HTTP-Autorisierungsmechanismen für die Benutzerauthentifizierung. SSH3 ermöglicht unter anderem folgende Verbesserungen:
[!TIP] Möchten Sie schnell loslegen? Erfahren Sie, wie Sie SSH3 installieren. Sie lernen, einen SSH3-Server einzurichten und den SSH3-Client zu verwenden.
Schneller beim Sitzungsaufbau, nicht beim Durchsatz! SSH3 bietet einen deutlich schnelleren Sitzungsaufbau als SSHv2. Der Aufbau einer neuen Sitzung mit SSHv2 kann 5 bis 7 Netzwerk-Roundtrips dauern, was der Benutzer leicht bemerken kann. SSH3 benötigt nur 3 Roundtrips. Die Tasteneingabelatenz in einer laufenden Sitzung bleibt unverändert.
SSH3 (oben) VS SSHv2 (unten) Sitzungsaufbau mit einem Ping von 100ms zum Server.
Während SSHv2 eigene Protokolle für Benutzerauthentifizierung und sicheren Kanalaufbau definiert, verlässt sich SSH3 auf die robusten und erprobten Mechanismen von TLS 1.3, QUIC und HTTP. Diese Protokolle werden bereits umfassend zur Sicherung sicherheitskritischer Internetanwendungen wie E-Commerce und Online-Banking eingesetzt.
SSH3 implementiert bereits die gebräuchlichen passwortbasierten und Public-Key-Authentifizierungsmethoden (RSA und EdDSA/ed25519). Es unterstützt auch neue Authentifizierungsmethoden wie OAuth 2.0 und ermöglicht die Anmeldung auf Ihren Servern mit Ihren Google-/Microsoft-/Github-Konten.
Obwohl SSH3 vielversprechend für einen schnelleren Sitzungsaufbau ist, befindet es sich noch in einem frühen Proof-of-Concept-Stadium. Wie bei jedem neuen komplexen Protokoll ist eine fachkundige kryptografische Überprüfung über einen längeren Zeitraum erforderlich, bevor vernünftige Sicherheitsschlussfolgerungen gezogen werden können.
Wir entwickeln SSH3 als Open-Source-Projekt, um Community-Feedback und -Analysen zu erleichtern. Wir können jedoch noch nicht seine Eignung für Produktionssysteme befürworten, ohne weitere Peer-Review. Bitte arbeiten Sie mit uns zusammen, wenn Sie über relevante Fachkenntnisse verfügen!
Angesichts des aktuellen Prototyp-Status raten wir, SSH3 in abgesicherten Umgebungen oder privaten Netzwerken zu testen. Beachten Sie, dass das direkte Bereitstellen experimenteller Server im Internet Risiken mit sich bringen kann, bevor eine gründliche Sicherheitsprüfung erfolgt ist.
Während das Verstecken von Servern hinter geheimen Pfaden potenzielle Vorteile bietet, ersetzt es nicht die Notwendigkeit einer rigorosen Schwachstellenanalyse vor dem Einsatz in der Produktion. Wir sind begeistert von den zukünftigen Möglichkeiten von SSH3, ermutigen jedoch zu zusätzlicher Prüfung.
Mit SSH3 können Sie den üblichen Stress von Scanning- und Wörterbuchangriffen auf Ihren SSH-Server vermeiden. Ähnlich wie bei Ihren geheimen Google-Drive-Dokumenten kann Ihr SSH3-Server hinter einem geheimen Link versteckt werden und nur auf Authentifizierungsversuche antworten, die eine HTTP-Anfrage an diesen spezifischen Link gestellt haben, wie folgt:
ssh3-server -bind 192.0.2.0:443 -url-path <my-long-secret>
Indem Sie <my-long-secret> durch, sagen wir, den zufälligen Wert M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU ersetzen, antwortet Ihr SSH3-Server nur auf SSH3-Verbindungsversuche, die an die URL https://192.0.2.0:443/M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU gerichtet sind, und antwortet auf andere Anfragen mit 404 Not Found. Angreifer und Crawler im Internet können daher die Anwesenheit Ihres SSH3-Servers nicht erkennen. Sie sehen nur einen einfachen Webserver, der auf jede Anfrage mit einem 404-Statuscode antwortet.
BEACHTEN SIE: Das Platzieren Ihres SSH3-Servers hinter einer geheimen URL kann die Auswirkungen von Scanning-Angriffen verringern, wird aber die klassischen Authentifizierungsmechanismen niemals ersetzen dürfen und muss nie. Der geheime Link sollte nur verwendet werden, um zu verhindern, dass Ihr Host entdeckt wird. Die Kenntnis der geheimen URL sollte niemandem Zugriff auf Ihren Server gewähren. Verwenden Sie die oben beschriebenen klassischen Authentifizierungsmechanismen, um Ihren Server zu schützen.
SSH3 bietet neue Funktionen, die das SSHv2-Protokoll nicht bieten konnte.
Diese SSH3-Implementierung bietet bereits viele der beliebten Funktionen von OpenSSH. Wenn Sie also OpenSSH gewohnt sind, wird der Umstieg auf SSH3 reibungslos verlaufen. Hier ist eine Liste einiger OpenSSH-Funktionen, die SSH3 ebenfalls implementiert:
~/.ssh/authorized_keys auf dem Serverknown_hosts-Mechanismus, wenn keine X.509-Zertifikate verwendet werden.ssh-agent für die Public-Key-Authentifizierung-proxy-jump). Wenn A ein SSH3-Client ist und B und C beide SSH3-Server sind, können Sie von A zu C über B als Gateway/Proxy verbinden. Der Proxy verwendet UDP-Weiterleitung, um die QUIC-Pakete von A nach C weiterzuleiten, sodass B den SSH3-Datenverkehr zwischen A und C nicht entschlüsseln kann.~/.ssh/config auf dem Client und verarbeitet die Konfigurationsoptionen Hostname, User, Port und IdentityFile (die anderen Optionen werden derzeit ignoriert). Analysiert auch ein neues UDPProxyJump, das sich ähnlich wie OpenSSHs ProxyJump verhält.Helfen Sie uns, SSH3 verantwortungsvoll voranzubringen! Wir heißen fähige Sicherheitsforscher willkommen, die unseren Code überprüfen und Feedback geben. Bitte vernetzen Sie uns auch mit relevanten Standardisierungsgremien, um SSH3 möglicherweise im Laufe der Zeit durch formelle IETF/IRTF-Prozesse voranzubringen.
Mit kollaborativer Unterstützung hoffen wir, SSH3 iterativ zu einer sicheren Produktionsreife zu verbessern. Wir können jedoch keine glaubwürdigen endgültigen Sicherheitsaussagen ohne Nachweise umfangreicher fachkundiger kryptografischer Überprüfung und Akzeptanz durch angesehene Sicherheitsbehörden machen. Lassen Sie uns zusammenarbeiten, um die Möglichkeiten von SSH3 zu verwirklichen!
Sie können entweder die letzten Release-Binärdateien herunterladen,
es mit go install installieren oder diese Binärdateien selbst erstellen, indem Sie den Quellcode kompilieren.
[!TIP] SSH3 ist noch experimentell und das Ergebnis einer Forschungsarbeit. Wenn Sie Angst haben, einen neuen SSH3-Server öffentlich bereitzustellen, können Sie die geheime Pfadfunktion von SSH3 nutzen, um ihn hinter einer geheimen URL zu verstecken.
go install github.com/francoismichel/ssh3/cmd/...@latest
Sie benötigen eine aktuelle Golang-Version, um dies zu tun. Das Herunterladen des Quellcodes und das Kompilieren der Binärdateien kann mit den folgenden Schritten durchgeführt werden:
git clone https://github.com/francoismichel/ssh3 # Klonen des Repos
cd ssh3
go build -o ssh3 cmd/ssh3/main.go # Erstellen des Clients
CGO_ENABLED=1 go build -o ssh3-server cmd/ssh3-server/main.go # Erstellen des Servers, erfordert installierten gcc
Wenn Sie Root-/sudo-Rechte haben und ssh3 für alle Benutzer zugänglich machen möchten,
können Sie die Binärdateien direkt nach /usr/bin kopieren:
cp ssh3 /usr/bin/ && cp ssh3-server /usr/bin
Andernfalls können Sie die ausführbaren Dateien einfach zu Ihrer PATH-Umgebungsvariable hinzufügen, indem Sie
die folgende Zeile am Ende Ihrer .bashrc oder einer gleichwertigen Datei hinzufügen:
export PATH=$PATH:/pfad/zum/ssh3/verzeichnis
Bevor Sie sich mit Ihrem Host verbinden, müssen Sie einen SSH3-Server darauf bereitstellen. Derzeit gibt es
keinen SSH3-Daemon, daher müssen Sie vorerst das ssh3-server-Programm im Hintergrund ausführen,
z. B. mit screen oder einem ähnlichen Dienstprogramm.
[!NOTE] Da SSH3 auf HTTP/3 läuft, benötigt ein Server ein X.509-Zertifikat und den zugehörigen privaten Schlüssel. Öffentliche Zertifikate können automatisch für Ihre öffentliche Domain über Let's Encrypt generiert werden, indem Sie das Befehlszeilenargument
-generate-public-certauf dem Server verwenden. Wenn Sie kein von einer echten Zertifizierungsstelle signiertes Zertifikat generieren möchten oder keine öffentliche Domain haben, können Sie ein selbstsigniertes Zertifikat mit dem Argument-generate-selfsigned-certgenerieren. Selbstsignierte Zertifikate bieten ähnliche Sicherheitsgarantien wie der SSHv2-Host-Key-Mechanismus, mit demselben Sicherheitsproblem: Sie sind während Ihrer ersten Verbindung zu Ihrem Server möglicherweise anfällig für Man-in-the-Middle-Angriffe. Die Verwendung echter, von öffentlichen Zertifizierungsstellen wie Let's Encrypt signierter Zertifikate vermeidet dieses Problem.
Hier ist die Verwendung des ssh3-server-Programms:
Usage of ./ssh3-server:
-bind string
das address:port-Paar, auf das gehört wird, z. B. 0.0.0.0:443 (default "[::]:443")
-cert string
der Dateiname des Serverzertifikats (oder der vollständigen Kette) (default "./cert.pem")
-key string
der Dateiname des privaten Schlüssels des Zertifikats (default "./priv.key")
-enable-password-login
wenn gesetzt, wird die Passwortauthentifizierung aktiviert (standardmäßig deaktiviert)
-generate-public-cert value
Automatisch ein gültiges öffentliches Zertifikat mit Let's Encrypt für den angegebenen Domainnamen erstellen und verwenden. Das Flag kann mehrmals verwendet werden, um mehrere Zertifikate zu generieren. Wenn Zertifikate zuvor mit diesem Flag generiert wurden, werden sie einfach wiederverwendet, ohne erneut generiert zu werden. Die öffentlichen Zertifikate werden automatisch erneuert, solange der Server läuft. Automatisch generierte öffentliche IP-Zertifikate sind noch nicht verfügbar.
-generate-selfsigned-cert
wenn gesetzt, wird ein selbstsigniertes Zertifikat und ein Schlüssel generiert, die unter den mit den Argumenten -cert und -key angegebenen Pfaden gespeichert werden (diese dürfen noch nicht existieren)
-url-path string
der geheime URL-Pfad, auf dem der SSH3-Server horcht (default "/ssh3-term")
-v ausführlicher Modus, wenn gesetzt
-version
wenn gesetzt, wird die Softwareversion auf der Standardausgabe angezeigt und beendet
Der folgende Befehl startet einen öffentlichen SSH3-Server auf Port 443 mit einem gültigen Let's-Encrypt-Public-Zertifikat
für die Domain my-domain.example.org und antwortet auf neue Sitzungsanfragen, die den URL-Pfad /ssh3 abfragen:
ssh3-server -generate-public-cert my-domain.example.org -url-path /ssh3
Wenn Sie keine öffentliche Domain haben (d. h. nur eine IP-Adresse), können Sie entweder ein vorhandenes Zertifikat
für Ihre IP-Adresse mit den Argumenten -cert und -key verwenden oder ein selbstsigniertes Zertifikat mit dem
Argument -generate-selfsigned-cert generieren.
Wenn Sie vorhandene Zertifikate und Schlüssel haben, können Sie den Server wie folgt starten, um diese zu verwenden:
ssh3-server -cert /pfad/zum/zertifikat/oder/vollkette -key /pfad/zum/privaten/schlüssel -url-path /ssh3
[!NOTE] Ähnlich wie bei OpenSSH muss der Server mit Root-Rechten ausgeführt werden, um sich als andere Benutzer anzumelden.
Standardmäßig sucht der SSH3-Server nach Identitäten in den Dateien ~/.ssh/authorized_keys und ~/.ssh3/authorized_identities für jeden Benutzer.
~/.ssh3/authorized_identities ermöglicht neue Identitäten wie OpenID Connect (oidc), das weiter unten besprochen wird.
Gängige Schlüsseltypen wie rsa, ed25519 und Schlüssel im OpenSSH-Format können verwendet werden.
Sobald ein SSH3-Server läuft, können Sie sich mit dem SSH3-Client analog zum klassischen SSHv2-Tool damit verbinden.
Hier ist die Verwendung des ssh3-Programms:
Usage of ssh3:
-pubkey-for-agent string
wenn gesetzt, verwende einen Agent-Key, dessen öffentlicher Schlüssel mit dem im angegebenen Pfad übereinstimmt
-privkey string
private Schlüsseldatei
-use-password
wenn gesetzt, klassische Passwortauthentifizierung durchführen
-forward-agent
wenn gesetzt, wird der SSH-Agent zur Verwendung mit SSHv2-Verbindungen auf dem entfernten Host weitergeleitet
-forward-tcp string
wenn gesetzt, wird eine localport/remoteip@remoteport Weiterleitung von localhost@localport zu remoteip@remoteport durchgeführt
-forward-udp string
wenn gesetzt, wird eine localport/remoteip@remoteport Weiterleitung von localhost@localport zu remoteip@remoteport durchgeführt
-proxy-jump string
wenn gesetzt, führt einen Proxy Jump unter Verwendung des angegebenen entfernten Hosts als Proxy durch
-insecure
wenn gesetzt, wird die Serverzertifikatsprüfung übersprungen
-keylog string
Schreibt QUIC-TLS-Schlüssel und Master-Secret in die angegebene Keylog-Datei: nur zu Debugging-Zwecken
-use-oidc string
wenn gesetzt, wird die Verwendung von OpenID Connect mit der angegebenen Issuer-URL als Parameter erzwungen
-oidc-config string
OpenID Connect JSON-Konfigurationsdatei mit den Feldern "client_id" und "client_secret", die für die meisten Identitätsanbieter benötigt werden
-do-pkce
wenn gesetzt, PKCE-Challenge-Response mit oidc durchführen
-v wenn gesetzt, ausführlichen Modus aktivieren
Sie können sich mit Ihrem SSH3-Server auf my-server.example.org, der auf /my-secret-path horcht, mit dem privaten Schlüssel in ~/.ssh/id_rsa mit folgendem Befehl verbinden:
ssh3 -privkey ~/.ssh/id_rsa [email protected]/my-secret-path
Der SSH3-Client arbeitet mit dem OpenSSH-Agenten zusammen und verwendet die klassische Umgebungsvariable SSH_AUTH_SOCK, um
mit diesem Agenten zu kommunizieren. Ähnlich wie OpenSSH listet SSH3 die vom SSH-Agenten bereitgestellten Schlüssel auf
und verbindet sich standardmäßig mit dem ersten vom Agenten aufgeführten Schlüssel.
Wenn Sie einen bestimmten Schlüssel verwenden möchten, den der Agent bereitstellt, können Sie entweder den privaten Schlüssel
direkt mit dem Argument -privkey wie oben angeben oder den entsprechenden öffentlichen Schlüssel mit dem
Argument -pubkey-for-agent angeben. Dies ermöglicht Ihnen die Authentifizierung in Situationen, in denen nur der Agent
direkten Zugriff auf den privaten Schlüssel hat, Sie aber nur Zugriff auf den öffentlichen Schlüssel haben.
Obwohl davon abgeraten wird, können Sie sich mit Passwörtern mit Ihrem Server verbinden (sofern auf dem ssh3-server explizit aktiviert),
indem Sie den folgenden Befehl verwenden:
ssh3 -use-password [email protected]/my-secret-path
ssh3 analysiert Ihre OpenSSH-Konfiguration. Derzeit werden nur die OpenSSH-Optionen Hostname; User, Port und IdentityFile verarbeitet.
Es werden auch neue Optionen hinzugefügt, die nur von SSH3 verwendet werden, wie URLPath oder UDPProxyJump. URLPath ermöglicht es Ihnen, den geheimen URL-Pfad in Ihrem
SSH3-Befehl wegzulassen. UDPProxyJump ermöglicht Ihnen die Durchführung eines SSH3-Proxy-Jumps und hat dieselbe Bedeutung wie das Befehlszeilenargument -proxy-jump.
Angenommen, Sie haben die folgenden Zeilen in Ihrer OpenSSH-Konfigurationsdatei ~/.ssh/config:
IgnoreUnknown URLPath
Host my-server
HostName 192.0.2.0
User benutzername
IdentityFile ~/.ssh/id_rsa
URLPath /my-secret-path
Ähnlich wie bei OpenSSH wird Sie der folgende ssh3-Befehl mit dem SSH3-Server unter 192.0.2.0 auf UDP-Port 443 unter Verwendung der Public-Key-Authentifizierung mit dem privaten Schlüssel in .ssh/id_rsa verbinden:
ssh3 my-server/my-secret-path
Wenn Sie keine konfigurationsbasierte Nutzung von SSH3 wünschen, lesen Sie die folgenden Abschnitte, um zu erfahren, wie Sie die CLI-Parameter von ssh3 verwenden.
Diese Funktion ermöglicht es Ihnen, sich mit einem externen Identitätsanbieter wie dem Ihres Unternehmens oder einem anderen Anbieter, der den OpenID Connect-Standard implementiert, zu verbinden, z. B. Google Identity, Github oder Microsoft Entra. Der Authentifizierungsablauf ist in der nachstehenden GIF-Datei dargestellt.
Sichere Verbindung ohne privaten Schlüssel mit einem Google-Konto.
Die Art und Weise, wie die Verbindung zu Ihrem Identitätsanbieter hergestellt wird, ist in einer Datei namens ~/.ssh3/oidc_config.json konfiguriert.
Nachfolgend finden Sie eine Beispiel-config.json-Datei für die Verwendung mit einem Google-Konto. Diese Konfigurationsdatei ist ein Array
und kann mehrere Konfigurationen von Identitätsanbietern enthalten.
[
{
"issuer_url": "https://accounts.google.com",
"client_id": "<your_client_id>",
"client_secret": "<your_client_secret>"
}
]
Dies könnte sich in Zukunft ändern, aber derzeit müssen Sie, um diese Funktion mit Ihrem Google-Konto zum Laufen zu bringen, eine neue experimentelle Anwendung in Ihrer Google Cloud Console einrichten und Ihre E-Mail als autorisierte Benutzer hinzufügen.
Dies liefert Ihnen eine client_id und ein client_secret, die Sie dann in Ihrer ~/.ssh3/oidc_config.json setzen können. Auf der Serverseite müssen Sie nur die folgende Zeile in Ihre ~/.ssh3/authorized_identities einfügen:
oidc <client_id> https://accounts.google.com <email>
Wir erwägen derzeit, die Notwendigkeit der Angabe der client_id in der Datei authorized_identities in Zukunft zu entfernen.
Es kommt häufig vor, dass einige SSH-Hosts nur über ein Gateway erreichbar sind. SSH3 ermöglicht Ihnen die Durchführung eines Proxy-Jumps, ähnlich wie bei OpenSSH. Sie können von A aus über B als Gateway/Proxy eine Verbindung zu C herstellen. B und C müssen beide einen gültigen SSH3-Server ausführen. Dies funktioniert durch die Einrichtung einer UDP-Portweiterleitung auf B, um QUIC-Pakete von A nach C weiterzuleiten. Die Verbindung von A nach C ist daher vollständig Ende-zu-Ende, und B kann den SSH3-Datenverkehr zwischen A und C weder entschlüsseln noch verändern.