SSH3 - un shell sécurisé plus rapide et plus riche qui utilise HTTP/3

 (github.com/francoismichel)
8 points par GN⁺ 2025-09-28 | 1 commentaires | Partager sur WhatsApp
  • SSH3 est un protocole de shell sécurisé de nouvelle génération fonctionnant au-dessus de HTTP/3, et améliore fortement la vitesse d’établissement de session par rapport au SSHv2 traditionnel
  • Il établit un canal sécurisé via QUIC et TLS 1.3, et prend en charge des mécanismes d’authentification modernes comme OAuth 2.0 et OpenID Connect
  • Le serveur peut être dissimulé derrière un chemin secret, ce qui le rend plus résistant à des attaques comme le scan de ports, tout en offrant de nouvelles fonctionnalités comme le port forwarding UDP et le multipath QUIC
  • Il a déjà adopté plusieurs fonctions clés d’OpenSSH, mais le projet est encore au stade expérimental et son déploiement en environnement de production n’est pas recommandé
  • Beaucoup estiment que le nom SSH3 n’est pas approprié ; le brouillon de standardisation a donc été renommé en « Remote Terminals over HTTP/3 », et un changement de nom est en cours

Présentation du projet SSH3 et son importance

  • SSH3 est une solution open source qui redessine le protocole SSH existant pour l’adapter à HTTP/3 et aux technologies web modernes
    • Il réinterprète la sémantique du protocole de connexion SSH existant (RFC4254) au-dessus de HTTP/3 Extended CONNECT et d’un canal QUIC + TLS 1.3
  • Il a été proposé sous la forme du brouillon Internet IETF draft-michel-remote-terminal-http3, avec à la clé une forte réduction de la latence d’établissement de session et divers avantages, comme l’extension vers des méthodes d’authentification modernes
  • Par rapport aux autres implémentations SSH, il se distingue par des idées innovantes comme l’usage de QUIC et la configuration de serveurs dissimulés

Fonctions et caractéristiques principales

  • Établissement de session rapide
    • Alors qu’une connexion SSHv2 classique nécessite en moyenne 5 à 7 allers-retours réseau, SSH3 n’en demande que 3, ce qui réduit fortement la latence perçue par l’utilisateur
    • La latence de saisie au clavier reste au niveau habituel
  • Sécurité renforcée
    • Basé sur TLS1.3, QUIC et l’authentification HTTP, il s’appuie sur des protocoles de sécurité éprouvés déjà utilisés dans le e-commerce et la banque en ligne
    • Il prend en charge les méthodes à clé publique basées sur RSA et EdDSA/ed25519, ainsi que diverses méthodes d’authentification comme OAuth 2.0 et OpenID Connect
    • Il est également possible de se connecter avec un compte Google, Microsoft ou Github
  • Fonction de dissimulation du serveur
    • Le serveur peut être placé derrière une URL secrète spécifique (par ex. https://192.0.2.0:443/M3MzkxYWMx...) et ne répond que lorsqu’une requête d’authentification est envoyée vers cette URL
    • Pour toutes les autres requêtes, il renvoie 404 Not Found, ce qui empêche les attaquants et crawlers sur Internet de détecter l’existence du serveur
    • Toutefois, ce chemin secret ne remplace pas l’authentification ; il est donc vivement recommandé d’utiliser un mécanisme d’authentification distinct (clé publique, mot de passe, OIDC, etc.)
  • Projet expérimental en développement continu
    • Une validation structurelle rigoureuse de la sécurité reste nécessaire, et son adoption sur des serveurs de production n’est pas recommandée
    • Le projet recueille actuellement les retours de la communauté dans des environnements expérimentaux ou des réseaux fermés
  • Compatibilité OpenSSH et fonctions supplémentaires
    • Analyse de ~/.ssh/authorized_keys et known_hosts, intégration avec ssh-agent, port forwarding TCP/UDP, prise en charge de Proxy Jump
    • La prise en charge du forwarding UDP permet l’accès à des serveurs basés sur UDP, comme les services DNS, RTP et QUIC, via un chemin QUIC datagram
    • Fonction d’authentification serveur de niveau HTTPS via des certificats X.509
    • Authentification sans clé (Keyless) : via OpenID Connect, il est possible de se connecter sans copier de clé publique, uniquement avec un SSO d’entreprise ou un compte externe comme Google ou Github

Conclusion

  • SSH3 est un projet open source expérimental qui fait évoluer l’environnement SSH en y introduisant des protocoles réseau modernes et des mécanismes d’authentification modernes
  • Il renforce fortement la vitesse, la flexibilité et la sécurité, mais il faut rester prudent avant tout usage en production tant qu’il n’a pas été suffisamment validé
  • Il offre une expérience utilisateur proche d’OpenSSH, tout en ajoutant de nombreuses nouvelles fonctionnalités.
  • Avec une évaluation de sécurité sérieuse et la participation de la communauté, il pourrait s’imposer comme le SSH de nouvelle génération

À lire aussi

1 commentaires

 
GN⁺ 2025-09-28
Avis Hacker News
  • Je n’aimais vraiment pas le nom ssh3, donc j’ai apprécié de voir tout en haut du dépôt : « SSH3 va être renommé. Pour l’instant, il s’agit encore du SSH Connection Protocol (RFC4254) fonctionnant au-dessus de HTTP/3 Extended CONNECT, mais il y a trop de changements nécessaires et c’est trop différent de SSH existant pour pouvoir être intégré facilement. Le brouillon de spécification a déjà été renommé en “Remote Terminals over HTTP/3”, et nous avons besoin de temps pour trouver un meilleur nom pérenne. »
    • Ce genre de nom donne l’impression que quelqu’un a créé un dépôt appelé « Windows 12 » ou « Linux 7 », ça sonne à côté de la plaque.
    • Proposition de nom à la place de SSH3 : Secure Hypertext Interactive TTY.
    • Je me suis demandé ce que vaudrait SSH/3 (dans l’esprit SSH + HTTP/3).
    • Ce thread est vraiment un grand classique du débat de « bike-shedding ».
    • Je me suis dit que SSH2/3 pourrait aller aussi, puisque c’est surtout SSH2 au-dessus de HTTP/3.
  • SSH est lent, et d’après mon expérience le plus gros goulot d’étranglement se situe dans l’établissement de session. Que ce soit à cause de PAM, ou des politiques d’OpenBSD, l’étape de configuration de session est terriblement lente à chaque fois, qu’on réutilise une connexion SSH ou qu’on en crée une nouvelle. Pour les sessions longues ça passe, mais dès qu’on veut juste exécuter une commande simple, il y a toujours ce surcoût ; je n’étais pas satisfait non plus des performances d’Ansible, alors j’ai fini par créer moi-même un mini ansible pour exécuter des commandes distantes sans surcharge de session.
  • J’étais sceptique sur le « c’est vraiment plus rapide que le SSH traditionnel ? », mais en lisant le README j’ai compris que seule la phase d’établissement de connexion était plus rapide, et qu’ensuite le débit réel restait identique. Rien que ça, c’est déjà une amélioration valable.
    • En réalité, ce n’est pas plus rapide dans ce sens-là. Quand on fait du forwarding de trafic sur plusieurs ports via une seule connexion SSH, on a du head-of-line blocking ; le protocole QUIC/HTTP3 peut résoudre ce problème.
    • Je veux bien parier que ce protocole sera bien plus rapide que SSH sur des liens à forte latence, puisqu’il repose sur UDP et peut envoyer un gros volume de données en continu sans attendre les ACK ; pour transférer de gros fichiers avec scp depuis différents endroits du monde, j’attends un vrai gain de vitesse.
    • Au-dessus d’un VPN, ça peut être vraiment plus rapide, parce qu’on évite le piège du « TCP dans TCP ».
    • Le principal avantage de HTTP/3 et de QUIC en général, c’est justement la réduction du nombre d’aller-retour, ce qui va dans le même sens qu’un établissement de connexion plus rapide.
  • L’explication était : « SSHv2 a besoin d’environ 5 à 7 aller-retour pour initialiser une session, alors que SSH3 n’en nécessite que 3. Pendant la session proprement dite, la latence d’entrée (temps entre frappe et réponse) est identique. » En tant qu’utilisateur, je n’ai jamais vraiment été gêné par la vitesse de connexion, donc je ne trouve pas ça très attirant. SSH a aussi une fiabilité éprouvée au combat, et même si ce nouvel outil était réellement prêt pour la production, lui faire confiance reste risqué.
    • Le tunnel UDP est une fonctionnalité clé ; c’est bien plus léger que WireGuard, avec en plus de l’authentification OpenID et ce genre de choses.
    • La « vitesse de connexion » m’a toujours un peu agacé. C’était particulièrement frustrant quand je voulais simplement lancer une commande à distance.
    • Avec ssh3, le head-of-line blocking a probablement disparu ; si on multiplexe plusieurs ports ou connexions sur une même connexion physique, ce sera plus rapide.
    • Si vous cherchez une expérience utilisateur plus fluide, je recommande Mosh.
  • Je ne sais pas pourquoi, mais voir tous les protocoles de couche applicative se faire absorber par HTTP me donne une impression triste.
    • Si la tendance est vraiment celle-là, oui, c’est triste. Le modèle typique de HTTP est trop contraignant et trop complexe dans beaucoup de cas. Mais HTTP/2 et QUIC (le transport de HTTP/3) sont devenus tellement génériques que le nom HTTP lui-même semble perdre une grande partie de son sens. Au moins, QUIC est utilisé avec un positionnement assez clair comme remplaçant de TCP.
    • En fait, si tous les protocoles sont standardisés de cette manière, je trouve ça plutôt positif, parce que ça rend le traffic shaping, la censure, etc. plus difficiles. Au final, si le trafic est du HTTP ou un flux d’octets aléatoire — autrement dit, s’il ne se fait pas remarquer —, la surveillance et le blocage réseau deviennent plus compliqués. Si on crée un nouveau protocole, à moins qu’un opérateur ait un intérêt particulier à le favoriser, le masquer en HTTP est le moyen le plus sûr de le faire passer sans ralentissement.
    • Ce phénomène vient aussi du fait que les équipes sécurité en entreprise veulent tout bloquer ou tout intercepter. Oui, c’est à vous que je pense, les équipes qui utilisent Zscaler ou le mode TLS man-in-the-middle.
    • Ce type de blocage existe aussi sur les Wi-Fi d’aéroport ou dans les hôtels du monde entier. Par exemple, Apple Mail ne peut parfois plus envoyer d’e-mails parce que des politiques d’entreprise bloquent le port 25. Sous prétexte de lutter contre le spam, ils bloquent aussi les ports 143, 587, 993, etc., et au final ne laissent passer que 80 et 443. J’espère qu’IPv6 améliorera un peu les choses. Et j’aimerais aussi que des initiatives comme ChatControl dans l’UE s’arrêtent. Il faudrait vraiment écouter les gens qui connaissent l’IT.
    • Je comprends aussi qu’avec la complexité croissante de l’initialisation de connexion au réseau, on finisse par s’appuyer sur les bonnes pratiques fondées sur des protocoles éprouvés. Mais continuer à appeler ça HTTP alors que le transport réel n’est plus de l’hypertexte donne une impression étrange.
  • Voir les fonctionnalités de SSH évoluer, c’est très bien, mais quitte à quasiment tout refaire, j’aurais aimé qu’on y ajoute aussi des fonctionnalités nouvelles plus expérimentales. Par exemple, des fonctions de confort à la Mosh pour gérer l’itinérance ou l’instabilité réseau temporaire seraient bienvenues https://mosh.org/.
    • L’avantage de Mosh, c’est que la réactivité à la frappe est incroyablement bonne, au point d’avoir l’impression de travailler directement dans un shell local. Je me demande si SSH3 améliore quelque chose sur ce point. QUIC compensera peut-être un peu, mais ce n’est pas la même chose que Mosh.
    • Si j’ai bien compris, la migration de connexion et le support multipath sont des propriétés natives de QUIC, et concernant la différence entre l’itinérance et un « tmux intégré », je ne sais pas si le fait que ce soit directement intégré au système apporte une vraie valeur.
  • Je me demande ce qui pousse les gens à s’obséder autant sur les noms courts et les sigles, c’est vraiment pénible. À ce stade, je pense qu’on peut très bien avoir des commandes longues et qu’il vaut mieux choisir des noms longs techniquement explicites. Il faudrait utiliser le nom complet par défaut, et laisser certains administrateurs système ou certaines distributions l’abréger si besoin. C’est le nom complet qu’il faut enseigner aux gens. Par exemple, Set-Location est préférable à cd, et un nom comme remote-terminals-over-http3 est meilleur que ssh3.
  • Le dernier commit date d’il y a un an ; quelqu’un sait où en est le projet récemment ?
  • Je me suis mis à me demander quels étaient les plans du projet. Plus aucune sortie ni activité GitHub depuis plus d’un an. Comme ça a commencé sous forme d’article de recherche, je me dis qu’ils poursuivent peut-être des travaux liés ou d’autres activités annexes.
    • Merci d’avoir souligné ce point. Personnellement, j’en conclus que ce projet est probablement mort maintenant. Avec environ 239 commits, ça reste essentiellement une preuve de concept, pas quelque chose de vraiment sérieux à utiliser aujourd’hui. À l’inverse, OpenBSD/OpenSSH reste extrêmement actif, donc on est encore très loin d’un remplacement crédible https://github.com/openbsd/src/commits/master/
  • L’idée du projet est bonne. Ce serait particulièrement prometteur si le trafic pouvait être relayé via un proxy H3 standard. Et si en plus ils règlent le multipath, la migration et les problèmes de blocage liés à TCP, ce serait déjà un énorme progrès.