Journal SSH3 n’est pas la suite d’SSH

Posté par  . Licence CC By‑SA.
Étiquettes :
31
30
sept.
2025

J’attends depuis l’arrivée du protocole QUIC, son utilisation dans SSH. En effet l’utilisation des channels me parait très intéressant pour par exemple n’utiliser qu’une seule connexion pour transférer des fichiers et garder son shell.

J’étais donc très intéressé quand j’ai vu une news de korben.info sur SSH3 https://korben.info/ssh3-serveurs-invisibles-http3-quic-revolution.html

J’ai par contre vite été surpris que ça parle de faire du SSH over HTTP/3. Les sources qu’il donne son un lien IETF https://datatracker.ietf.org/doc/draft-michel-ssh3/ et du code https://github.com/francoismichel/ssh3.

On se calme tout de suite si korben veut mettre au placard le SSH qu’on connait, le truc dont il parle est mort avant même d’avoir été publié sur son site. C’est une personne qui s’est chauffée mais qui semble n’avoir plus rien fait depuis un an et demi. La proposition IETF est archivée.

Ce n’est en rien une nouvelle version de SSH et rien chez OpenSSH n’est lié à ce truc.

Autant je trouve qu’il n’y a pas de mal à tenter des choses autant je trouve la présentation par korben désastreuse :

  • ne pas vérifier si le projet est encore en vie (ou même considéré comme bon pour la prod)
  • le présenter comme la suite de SSH alors qu’il n’en est rien et qu’on a aucun moyen de se rassurer sur la solidité du truc

Bref je voulais faire un petit journal pour que SSH3 ne renvoie pas que le billet de korben sur les moteurs de recherches en français.

  • # Partage de connexion ssh / multiplexing

    Posté par  . Évalué à 10 (+12/-0).

    Ce que tu cherches existe probablement déjà dans openssh: https://man.openbsd.org/ssh_config#ControlMaster

    • [^] # Re: Partage de connexion ssh / multiplexing

      Posté par  . Évalué à 3 (+1/-0).

      C’est vrai. J’avoue que c’est avant tout de la curiosité intellectuelle.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Partage de connexion ssh / multiplexing

      Posté par  (site web personnel) . Évalué à 3 (+2/-0).

      Je plusse, on s'en rend peu compte depuis son terminal, mais si on utilise programmatiquement le protocole SSH on découvre tout de suite qu'il est déjà multiplexé : une connection SSH transporte autant de "canaux" que l'on souhaite (apparu dans le protocole v2 en 2006).

      On peut être très créatif avec ça. Depuis les outils CLI on s'en rend compte par ex. en faisant ssh -L 8080:1.2.3.4:80 -X bob@server : on se retrouve bien avec en parallèle 1/ un flux vers un shell interactif, 2/ un flux TCP forwardé, 3/ le flux X11 TCP forwardé (3 "canaux" pour 1 connection).

      Le multiplexage QUIC éviterai le fameux "head-of-line blocking" (en TCP si un paquet est perdu, tous les flux multiplexés au sein de la connection TCP sont concernés/retardés). Mais dans la très vaste majorité des cas SSH est utilisé avec un canal par session (typiquement shell, tunnel, ou forward-only [option -N]). Du coup je doute que ça intéresse grand monde.

  • # C'est drôle les tendances

    Posté par  . Évalué à 5 (+3/-0).

    Vu ces derniers jours sur Mastodon : nixCraft poste un lien vers le repo moribond. Korben poste un article, Stéphane Bortzmeyer poste un lien vers l'article de Korben.

    Et puis https://mastodon.social/@tbr@society.oftrolls.com/115278018820033429 :

    The project seems to have dropped dead at the exact time the main person behind it switched from PhD at university to working for Apple.
    This thing is not going anywhere.

    Ce qui est compréhensible, c'est sans doute un projet assez vaste. Bon, peut-être que ça va piquer l'orgueil des personnes qui développement SSH et qu'elles vont ajouter QUIC rapidement :).

    • [^] # Re: C'est drôle les tendances

      Posté par  . Évalué à 7 (+6/-1).

      Vu ces derniers jours sur Mastodon : nixCraft poste un lien vers le repo moribond. Korben poste un article, Stéphane Bortzmeyer poste un lien vers l'article de Korben.

      Je trouve dommage de se faire le relais de choses sans s’être intéressé au truc. Ce n’est vraiment pas un gros travail de se rendre compte que le projet n’a aucune filiation avec ssh et qu’il est mort. Pour des personnes comme korben dont c’est le métier, je trouve que c’est un problème. Si son travail n’est que de rédiger des articles à la va vite à partir de README hasardeux trouvé sur github, il n’a pas besoin d’un humain pour le faire.

      Bon, peut-être que ça va piquer l'orgueil des personnes qui développement SSH et qu'elles vont ajouter QUIC rapidement :).

      De ce que j’imagine d’eux, ils vont surtout faire bien attention à continuer à faire ce qu’ils font sans rien changer.

      Ce qui est compréhensible, c'est sans doute un projet assez vaste.

      Il y a vraiment des trucs qui me font tiquer dans ce qui était proposé comme le fait de passer à TLS (techniquement d’avoir du SSH dans du TLS) ce qui change le modèle de sécurité.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: C'est drôle les tendances

        Posté par  . Évalué à 3 (+1/-0).

        Bon, peut-être que ça va piquer l'orgueil des personnes qui développement SSH et qu'elles vont ajouter QUIC rapidement :).

        De ce que j’imagine d’eux, ils vont surtout faire bien attention à continuer à faire ce qu’ils font sans rien changer.

        Ah ah bien vu ! C'est sans doute fort vrai… C'est d'ailleurs ce qu'il s'est passé dirait-on :).

        Dans le même goût, il y a un projet, qui s'appelle hpn-ssh, qui est, pour faire court, un patch d'OpenSSH pour pouvoir faire des transferts de fichiers super rapides. Il y a eu demande et débat, sur le bien fondé d'intégrer ça dans OpenSSH, et la réponse a été non. L'argument étant que ça fait plus de code à maintenir pour un cas qui n'intéresse pas l'équipe. L'équipe préfère se concentrer sur l'aspect shell et pas l'aspect transfert de fichiers.

      • [^] # Re: C'est drôle les tendances

        Posté par  . Évalué à 4 (+3/-0).

        Bah, ça fait un moment que Korben fait globalement dans le "QUIC & Dirty" niveau publications…

        J'ai été un lecteur régulier, mais plus depuis sans doute 10 ans… jusqu'à ce que cette news me rappelle sa simple existence et que je retourne y voir: Clairement, il reste au top de la modernité et semble avoir carrément refilé les clefs du site à une IA?!!

  • # sorte d'usurpation de nom

    Posté par  . Évalué à 10 (+8/-0).

    c'est simplement une sorte d'usurpation de nom, l'auteur en a même conscience car d'après le dépôt de ce "ssh3" :

    SSH3 is probably going to change its name. It is still the SSH Connection Protocol (RFC4254) running on top of HTTP/3 Extended connect, but the required changes are heavy and too distant from the philosophy of popular SSH implementations to be considered for integration.

    bon, par contre il y a aussi une différence entre openssh et l'implémentation du protocole, puisque si ssh3 utilise le RFC4254 ce n'est pas complètement étranger (reste à savoir s'il reste compatible avec tous les aspects du protocole). Ce qui est un peu trompeur quand même c'est que le 3 accolé donne l'impression que c'est LA nouvelle version officielle.

    Rappel important : vos amis qui se sont retournés contre vous parce que la TV leur a dit de le faire : ils le feront encore.

    • [^] # Re: sorte d'usurpation de nom

      Posté par  (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 30 septembre 2025 à 08:56.

      Sur la page Wikipedia de SSH il y a bien un chapitre dessus. (plus léger en version française, mais ça reste dit comme non officiel).

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # coquille

    Posté par  . Évalué à 3 (+1/-0).

    s/avant même d’avoir était publié/avant même d’avoir été publié/

  • # Mosh

    Posté par  . Évalué à 4 (+2/-0).

    Et si le but c'est de faire du SSH over UDP pour les avantages de l'itinérance et des problèmes de connexion dégradées, il existe le projet Mosh : https://mosh.org/ .
    À l'époque où je l'utilisais, c'était vraiment bien.

  • # Quel intérêt ?

    Posté par  (site web personnel) . Évalué à 2 (+1/-0).

    Quels seraient les avantages d'un SSH over QUIC ? De ce que je comprends l'avantage principal de QUIC est le multiplexage sans que ça pénalise le débit. Dans SSH il n'y pas vraiment d'intérêt au multiplexage vu qu'il n'y a qu'un shell. Du coup on y gagne quoi?

    Niveau sécurité je ne vois pas vraiment d'avancée, SSH supporte déjà pléthore de méthodes d'authentifications et son protocole est éprouvé, au contraire de QUIC.

    De plus HTTP/2 et QUIC ont déjà pas mal de CVE à leur actif, forcément gérer du multiplexage rend les implémentations assez complexes.

    • [^] # Re: Quel intérêt ?

      Posté par  . Évalué à 2 (+0/-0).

      Dans SSH il n'y pas vraiment d'intérêt au multiplexage vu qu'il n'y a qu'un shell.

      Ça dépend des usages. Avec SFTP il n’y a pas qu’un shell, avec les bastions SSH non plus. C’est bien pour ça qu’il y a des fonctionnalités de multiplexage intégrées.

      Et du coup pour le gain, il faut tester pour le vérifier, mais on peut imaginer qu’un rsync -e ssh puisse en bénéficier.

      Niveau sécurité je ne vois pas vraiment d'avancée, SSH supporte déjà pléthore de méthodes d'authentifications et son protocole est éprouvé, au contraire de QUIC.

      QUIC et HTTP/3 n’ont rien à voir avec l’authentification. Pour ce qui est de la couche de chiffrement, je préfère effectivement le modèle de confiance de SSH à celui de TLS. Par contre dire que TLS n’est pas éprouvé ça demande des arguments. Même en ne s’intéressant qu’à la version 1.3, elle reprend une majorité d’éléments de la version 1.2 et depuis maintenant 7 ans il est massivement utilisé.

      De plus HTTP/2 et QUIC ont déjà pas mal de CVE à leur actif, forcément gérer du multiplexage rend les implémentations assez complexes.

      HTTP/2 est un protocole conçu de manière un peu trop précipité et a reçu une adoption toute relative. QUIC a effectivement des CVE dans ces implémentations, mais ce à mon avis pas un argument suffisant. Le multiplexage a déjà était implémenté malgré le risque.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Quel intérêt ?

        Posté par  (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 04 octobre 2025 à 10:14.

        HTTP/2 est un protocole conçu de manière un peu trop précipité et a reçu une adoption toute relative.

        ça n'a pas l'air d'être la joie sur HTTP/1.1 non plus, cf HTTP/1.1 must die: the desync endgame.

      • [^] # Re: Quel intérêt ?

        Posté par  (site web personnel) . Évalué à 3 (+2/-0).

        Le draft SSH3 propose un mécanisme d'authentification assez différent de celui de SSH, bien entendu c'est pas géré par QUIC. Je pense d'ailleurs que c'est le côté le plus bancal de ce draft, car ça rend la migration quasiment impossible depuis SSH.

        TLS c'est éprouvé, mais TLS sur QUIC un peu moins. Le protocole peut être solide, mais il y a toujours un risque qu'une implémentation récente ne soit pas suffisamment robuste.

        En effet il pourrait y avoir un intérêt avec SFTP, mais si on veut faire de l'échange de fichier autant utiliser HTTP/3 directement !

        Donc pour moi le rapport risque / bénéfice est vraiment trop élevé.

      • [^] # Re: Quel intérêt ?

        Posté par  . Évalué à 2 (+0/-0).

        Je suis assez d'accord que quand on fait du SFTP ou du rsync par-dessus SSH, on gagnerai à avoir un protocole de transfert de données rapide et performant… Ce que SSH n'est pas.

        C'est ptet le moment de se dire qu'il faudrait un tel truc, mais séparé de SSH ? J'utilisais UDT/UDR, qui est plus ou moins abandonné. J'avais essayé WDT qui dépote pas mal, mais il lui manquait quelques options que seul rsync supportait à l'époque, ça a peut-être changé depuis.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.