francoismichel/ssh3Protocole shell rapide et sécurisé basé sur HTTP/3, QUIC et TLS 1.3. Prend en charge OAuth2, OpenID Connect et l'authentification SSH classique avec le transfert de ports UDP et les capacités de serveur caché.
[!NOTE] SSH3 va probablement changer de nom. Il s'agit toujours du protocole de connexion SSH (RFC4254) fonctionnant sur HTTP/3 Extended Connect, mais les modifications nécessaires sont lourdes et trop éloignées de la philosophie des implémentations SSH populaires pour être envisagées en vue d'une intégration. Le projet de spécification a déjà été renommé (« Remote Terminals over HTTP/3 »), mais nous avons besoin de temps pour trouver un joli nom permanent.
SSH3 est une refonte complète du protocole SSH, mappant sa sémantique sur les mécanismes HTTP. Il est issu de nos travaux de recherche et nous (chercheurs) l'avons récemment proposé comme Internet-Draft (draft-michel-remote-terminal-http3-00).
En résumé, SSH3 utilise QUIC+TLS1.3 pour l'établissement d'un canal sécurisé et les mécanismes d'Autorisation HTTP pour l'authentification des utilisateurs. Entre autres, SSH3 permet les améliorations suivantes :
[!TIP] Vous voulez démarrer rapidement ? Découvrez comment installer SSH3. Vous apprendrez à mettre en place un serveur SSH3 et à utiliser le client SSH3.
Plus rapide pour l'établissement de session, pas pour le débit ! SSH3 offre un établissement de session significativement plus rapide que SSHv2. Établir une nouvelle session avec SSHv2 peut prendre 5 à 7 allers-retours réseau, ce qui peut facilement être remarqué par l'utilisateur. SSH3 ne nécessite que 3 allers-retours. La latence des frappes dans une session en cours est inchangée.
SSH3 (haut) VS SSHv2 (bas) établissement de session avec un ping de 100ms vers le serveur.
Alors que SSHv2 définit ses propres protocoles pour l'authentification des utilisateurs et l'établissement de canaux sécurisés, SSH3 s'appuie sur les mécanismes robustes et éprouvés de TLS 1.3, QUIC et HTTP. Ces protocoles sont déjà largement utilisés pour sécuriser des applications critiques pour la sécurité sur Internet, comme le commerce en ligne et les services bancaires en ligne.
SSH3 implémente déjà les méthodes d'authentification courantes par mot de passe et par clé publique (RSA et EdDSA/ed25519). Il supporte également de nouvelles méthodes d'authentification telles que OAuth 2.0 et permet de vous connecter à vos serveurs en utilisant vos comptes Google/Microsoft/Github.
Bien que SSH3 montre des promesses pour un établissement de session plus rapide, il en est encore à un stade précoce de preuve de concept. Comme pour tout nouveau protocole complexe, un examen cryptographique expert sur une période prolongée est nécessaire avant de pouvoir tirer des conclusions de sécurité raisonnables.
Nous développons SSH3 en tant que projet open source pour faciliter les retours et l'analyse de la communauté. Cependant, nous ne pouvons pas encore approuver son adéquation pour des systèmes de production sans examen supplémentaire par des pairs. Veuillez collaborer avec nous si vous avez l'expertise appropriée !
Compte tenu de l'état actuel du prototype, nous conseillons de tester SSH3 dans des environnements sandbox ou des réseaux privés. Sachez que rendre des serveurs expérimentaux directement accessibles sur Internet pourrait introduire des risques avant un examen de sécurité approfondi.
Bien que cacher les serveurs derrière des chemins secrets présente des avantages potentiels, cela ne supprime pas la nécessité d'une analyse rigoureuse des vulnérabilités avant la mise en production. Nous sommes enthousiastes quant aux possibilités futures de SSH3 mais encourageons un examen supplémentaire au préalable.
Avec SSH3, vous pouvez éviter le stress habituel des attaques de balayage et de dictionnaire contre votre serveur SSH. Comme pour vos documents Google Drive secrets, votre serveur SSH3 peut être caché derrière un lien secret et ne répondre qu'aux tentatives d'authentification qui ont effectué une requête HTTP à ce lien spécifique, comme suit :
ssh3-server -bind 192.0.2.0:443 -url-path <my-long-secret>
En remplaçant <my-long-secret> par, disons, la valeur aléatoire M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU, votre serveur SSH3 ne répondra qu'aux tentatives de connexion SSH3 adressées à l'URL https://192.0.2.0:443/M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU et répondra 404 Not Found aux autres requêtes. Les attaquants et robots d'exploration sur Internet ne peuvent donc pas détecter la présence de votre serveur SSH3. Ils ne verront qu'un simple serveur web répondant des codes de statut 404 à chaque requête.
À NOTER : placer votre serveur SSH3 derrière une URL secrète peut réduire l'impact des attaques par balayage mais ne remplacera et ne doit jamais remplacer les mécanismes d'authentification classiques. Le lien secret ne devrait être utilisé que pour éviter que votre hôte ne soit découvert. Connaître l'URL secrète ne devrait pas donner accès à votre serveur. Utilisez les mécanismes d'authentification classiques décrits ci-dessus pour protéger votre serveur.
SSH3 offre de nouvelles fonctionnalités que le protocole SSHv2 ne pouvait pas fournir.
Cette implémentation de SSH3 fournit déjà de nombreuses fonctionnalités populaires d'OpenSSH, donc si vous avez l'habitude d'OpenSSH, le processus d'adoption de SSH3 sera fluide. Voici une liste de certaines fonctionnalités d'OpenSSH que SSH3 implémente également :
~/.ssh/authorized_keys sur le serveurknown_hosts lorsque les certificats X.509 ne sont pas utilisés.ssh-agent pour l'authentification par clé publique-proxy-jump). Si A est un client SSH3 et B et C sont tous deux des serveurs SSH3, vous pouvez vous connecter de A à C en utilisant B comme passerelle/proxy. Le proxy utilise le transfert UDP pour transférer les paquets QUIC de A à C, donc B ne peut pas déchiffrer le trafic SSH3 A<->C.~/.ssh/config sur le client et gestion des options de configuration Hostname, User, Port et IdentityFile (les autres options sont actuellement ignorées). Analyse également une nouvelle option UDPProxyJump qui se comporte de manière similaire à ProxyJump d'OpenSSH.Aidez-nous à faire progresser SSH3 de manière responsable ! Nous accueillons les chercheurs en sécurité compétents pour examiner notre code et fournir des retours. Veuillez également nous mettre en relation avec les organismes de normalisation compétents pour potentiellement faire avancer SSH3 via les processus formels de l'IETF/IRTF au fil du temps.
Avec une assistance collaborative, nous espérons améliorer SSH3 de manière itérative pour atteindre une maturité de production sûre. Mais nous ne pouvons pas faire de déclarations de sécurité définitives crédibles sans preuve d'un examen cryptographique expert approfondi et d'une adoption par des autorités de sécurité respectées. Travaillons ensemble pour réaliser les possibilités de SSH3 !
Vous pouvez soit télécharger les binaires de la dernière version,
l'installer en utilisant go install ou générer ces binaires vous-même en compilant le code source.
[!TIP] SSH3 est encore expérimental et est le fruit d'un travail de recherche. Si vous craignez de déployer publiquement un nouveau serveur SSH3, vous pouvez utiliser la fonctionnalité de chemin secret de SSH3 pour le cacher derrière une URL secrète.
go install github.com/francoismichel/ssh3/cmd/...@latest
Vous avez besoin d'une version récente de Golang pour cela. Télécharger le code source et compiler les binaires peut se faire avec les étapes suivantes :
git clone https://github.com/francoismichel/ssh3 # cloner le dépôt
cd ssh3
go build -o ssh3 cmd/ssh3/main.go # construire le client
CGO_ENABLED=1 go build -o ssh3-server cmd/ssh3-server/main.go # construire le serveur, nécessite d'avoir gcc installé
Si vous avez les privilèges root/sudo et que vous souhaitez rendre ssh3 accessible à tous vos utilisateurs,
vous pouvez ensuite copier directement les binaires dans /usr/bin :
cp ssh3 /usr/bin/ && cp ssh3-server /usr/bin
Sinon, vous pouvez simplement ajouter les exécutables à votre variable d'environnement PATH en ajoutant
la ligne suivante à la fin de votre .bashrc ou équivalent :
export PATH=$PATH:/chemin/vers/le/dossier/ssh3
Avant de vous connecter à votre hôte, vous devez déployer un serveur SSH3 sur celui-ci. Il n'y a actuellement
pas de démon SSH3, donc pour l'instant, vous devrez exécuter l'exécutable ssh3-server en arrière-plan
en utilisant screen ou un utilitaire similaire.
[!NOTE] Comme SSH3 fonctionne sur HTTP/3, un serveur a besoin d'un certificat X.509 et de sa clé privée correspondante. Des certificats publics peuvent être générés automatiquement pour votre nom de domaine public via Let's Encrypt en utilisant l'argument de ligne de commande
-generate-public-certsur le serveur. Si vous ne souhaitez pas générer un certificat signé par une autorité de certification réelle ou si vous n'avez pas de nom de domaine public, vous pouvez en générer un auto-signé en utilisant l'argument-generate-selfsigned-cert. Les certificats auto-signés offrent des garanties de sécurité similaires au mécanisme de clé d'hôte SSHv2, avec le même problème de sécurité : vous pouvez être vulnérable aux attaques de type intermédiaire (MITM) lors de votre première connexion à votre serveur. L'utilisation de certificats réels signés par des autorités de certification publiques comme Let's Encrypt évite ce problème.
Voici l'utilisation de l'exécutable ssh3-server :
Usage of ./ssh3-server:
-bind string
l'adresse:port à écouter, ex. 0.0.0.0:443 (par défaut "[::]:443")
-cert string
le nom du fichier du certificat serveur (ou chaîne complète) (par défaut "./cert.pem")
-key string
le nom du fichier de la clé privée du certificat (par défaut "./priv.key")
-enable-password-login
si défini, active l'authentification par mot de passe (désactivé par défaut)
-generate-public-cert value
Produire et utiliser automatiquement un certificat public valide via Let's Encrypt pour le nom de domaine fourni. Le drapeau peut être utilisé plusieurs fois pour générer plusieurs certificats. Si des certificats ont déjà été générés précédemment avec ce drapeau, ils seront simplement réutilisés sans être régénérés. Les certificats publics sont automatiquement renouvelés tant que le serveur est en cours d'exécution. Les certificats publics IP générés automatiquement ne sont pas encore disponibles.
-generate-selfsigned-cert
si défini, génère un certificat et une clé auto-signés qui seront stockés aux chemins indiqués par les arguments -cert et -key (ils ne doivent pas déjà exister)
-url-path string
le chemin d'URL secret sur lequel le serveur ssh3 écoute (par défaut "/ssh3-term")
-v mode verbeux, si défini
-version
si défini, affiche la version du logiciel sur la sortie standard et quitte
La commande suivante démarre un serveur SSH3 public sur le port 443 avec un certificat public Let's Encrypt valide
pour le domaine my-domain.example.org et répond aux demandes de nouvelles sessions interrogeant le chemin d'URL /ssh3 :
ssh3-server -generate-public-cert my-domain.example.org -url-path /ssh3
Si vous n'avez pas de nom de domaine public (c'est-à-dire seulement une adresse IP), vous pouvez soit utiliser un certificat existant
pour votre adresse IP en utilisant les arguments -cert et -key, soit générer un certificat auto-signé en utilisant l'argument
-generate-selfsigned-cert.
Si vous avez des certificats et des clés existants, vous pouvez exécuter le serveur comme suit pour les utiliser :
ssh3-server -cert /chemin/vers/certificat/ou/chaîne -key /chemin/vers/cle/privée/certificat -url-path /ssh3
[!NOTE] Comme pour OpenSSH, le serveur doit être exécuté avec les privilèges root pour se connecter en tant qu'autres utilisateurs.
Par défaut, le serveur SSH3 recherche les identités dans les fichiers ~/.ssh/authorized_keys et ~/.ssh3/authorized_identities pour chaque utilisateur.
~/.ssh3/authorized_identities permet de nouvelles identités telles que OpenID Connect (oidc) discutées ci-dessous.
Les types de clés populaires tels que rsa, ed25519 et les clés au format OpenSSH peuvent être utilisés.
Une fois que vous avez un serveur SSH3 en cours d'exécution, vous pouvez vous y connecter en utilisant le client SSH3 de manière similaire à ce que vous faisiez avec votre outil SSHv2 classique.
Voici l'utilisation de l'exécutable ssh3 :
Usage of ssh3:
-pubkey-for-agent string
si défini, utilise une clé d'agent dont la clé publique correspond à celle présente dans le chemin spécifié
-privkey string
fichier de clé privée
-use-password
si défini, effectue une authentification classique par mot de passe
-forward-agent
si défini, transfère l'agent ssh pour être utilisé avec les connexions sshv2 sur l'hôte distant
-forward-tcp string
si défini, prend un transfert localport/remoteip@remoteport pour rediriger localhost@localport vers remoteip@remoteport
-forward-udp string
si défini, prend un transfert localport/remoteip@remoteport pour rediriger localhost@localport vers remoteip@remoteport
-proxy-jump string
si défini, effectue un saut proxy en utilisant l'hôte distant spécifié comme proxy
-insecure
si défini, ignore la vérification du certificat du serveur
-keylog string
Écrire les clés TLS QUIC et le secret maître dans le fichier keylog spécifié : uniquement à des fins de débogage
-use-oidc string
si défini, force l'utilisation d'OpenID Connect avec l'URL de l'émetteur spécifiée comme paramètre
-oidc-config string
Fichier de configuration JSON OpenID Connect contenant les champs "client_id" et "client_secret" nécessaires pour la plupart des fournisseurs d'identité
-do-pkce
si défini, effectue un challenge-réponse PKCE avec oidc
-v si défini, active le mode verbeux
Vous pouvez vous connecter à votre serveur SSH3 sur my-server.example.org écoutant sur /my-secret-path en utilisant la clé privée située dans ~/.ssh/id_rsa avec la commande suivante :
ssh3 -privkey ~/.ssh/id_rsa [email protected]/my-secret-path
Le client SSH3 fonctionne avec l'agent OpenSSH et utilise la variable d'environnement classique SSH_AUTH_SOCK pour
communiquer avec cet agent. Comme OpenSSH, SSH3 listera les clés fournies par l'agent SSH
et se connectera en utilisant la première clé écoutée par l'agent par défaut.
Si vous souhaitez spécifier une clé particulière à utiliser avec l'agent, vous pouvez soit spécifier directement la clé privée
avec l'argument -privkey comme ci-dessus, soit spécifier la clé publique correspondante en utilisant l'argument
-pubkey-for-agent. Cela vous permet de vous authentifier dans des situations où seul l'agent a
un accès direct à la clé privée mais vous n'avez accès qu'à la clé publique.
Bien que déconseillé, vous pouvez vous connecter à votre serveur en utilisant des mots de passe (si explicitement activé sur le ssh3-server) avec la commande suivante :
ssh3 -use-password [email protected]/my-secret-path
ssh3 analyse votre configuration OpenSSH. Actuellement, il ne gère que les options OpenSSH Hostname ; User, Port et IdentityFile.
Il ajoute également une nouvelle option uniquement utilisée par SSH3, comme URLPath ou UDPProxyJump. URLPath vous permet d'omettre le chemin d'URL secret dans votre
commande SSH3. UDPProxyJump vous permet d'effectuer un [saut proxy] SSH3 et a la même signification que l'argument de ligne de commande -proxy-jump.
Disons que vous avez les lignes suivantes dans votre configuration OpenSSH située dans ~/.ssh/config :
IgnoreUnknown URLPath
Host my-server
HostName 192.0.2.0
User nomdutilisateur
IdentityFile ~/.ssh/id_rsa
URLPath /my-secret-path
Comme le fait OpenSSH, la commande ssh3 suivante vous connectera au serveur SSH3 fonctionnant sur 192.0.2.0 sur le port UDP 443 en utilisant l'authentification par clé publique avec la clé privée située dans .ssh/id_rsa :
ssh3 my-server/my-secret-path
Si vous ne souhaitez pas une utilisation de SSH3 basée sur la configuration, vous pouvez lire les sections ci-dessous pour voir comment utiliser les paramètres CLI de ssh3.
Cette fonctionnalité vous permet de vous connecter en utilisant un fournisseur d'identité externe tel que celui de votre entreprise ou tout autre fournisseur implémentant la norme OpenID Connect, comme Google Identity, Github ou Microsoft Entra. Le flux d'authentification est illustré dans le GIF ci-dessous.
Connexion sécurisée sans clé privée en utilisant un compte Google.
La manière dont il se connecte à votre fournisseur d'identité est configurée dans un fichier nommé ~/.ssh3/oidc_config.json.
Voici un exemple de fichier config.json pour une utilisation avec un compte Google. Ce fichier de configuration est un tableau
et peut contenir plusieurs configurations de fournisseurs d'identité.
[
{
"issuer_url": "https://accounts.google.com",
"client_id": "<votre_client_id>",
"client_secret": "<votre_client_secret>"
}
]
Cela pourrait changer à l'avenir, mais actuellement, pour faire fonctionner cette fonctionnalité avec votre compte Google, vous devrez configurer une nouvelle application expérimentale dans votre console Google Cloud et ajouter votre email comme utilisateurs autorisés.
Cela vous fournira un client_id et un client_secret que vous pourrez ensuite définir dans votre ~/.ssh3/oidc_config.json. Côté serveur, il vous suffit d'ajouter la ligne suivante dans votre ~/.ssh3/authorized_identities :
oidc <client_id> https://accounts.google.com <email>
Nous envisageons actuellement de supprimer la nécessité de définir le client_id dans le fichier authorized_identities à l'avenir.
Il arrive souvent que certains hôtes SSH ne soient accessibles que via une passerelle. SSH3 vous permet d'effectuer un saut proxy de manière similaire à ce qui est proposé par OpenSSH. Vous pouvez vous connecter de A à C en utilisant B comme passerelle/proxy. B et C doivent tous deux exécuter un serveur SSH3 valide. Cela fonctionne en établissant un transfert de port UDP sur B pour transférer les paquets QUIC de A à C. La connexion de A à C est donc entièrement de bout en bout et B ne peut ni déchiffrer ni altérer le trafic SSH3 entre A et C.