[Linux Apps] Quicssh : booster vos connexions SSH
-
Connaissez-vous quicssh ?
Eh bien, c’est un proxy QUIC qui promet de révolutionner notre façon de se connecter à un serveur SSH.
Pour ceux qui ne le savent pas, QUIC est un protocole de transport qui vise à améliorer la vitesse des connexions et la sécurité sur Internet. Pour les plus anciens, ça vous rappeler peut être l’époque où vous avez découvert le TCP/IP… lol
L’architecture standard d’une connexion SSH fonctionne comme ceci :
Avec quicssh, pas besoin de modifier le client ou le serveur puisque tout est géré par le proxy QUIC. Ainsi, pour utiliser quicssh, il suffit d’exécuter les commandes client et serveur avec les options qui vont bien et votre connexion SSH transitera par QUIC comme ceci :
Pour l’installer, entrez la commande suivante :
go get -u moul.io/quicssh
Voilà, c’est aussi simple que ça ! Après pour le reste, je vous invite à lire la doc.
La différence de vitesse entre un client SSH traditionnel et Quicssh est assez remarquable. Je vous invite à faire vos propres tests, mais attention, Quicssh est un projet relativement jeune, donc attendez vous à quelques bugs, mais aussi à le voir s’améliorer dans les semaines qui viennent…
-
sinon ya putty non c’est du même accabi ? Merci pour le post
-
@Snoubi a dit dans [Linux Apps] Quicssh : booster vos connexions SSH :
sinon ya putty non c’est du même accabi ? Merci pour le post
Euhh c’est du troll ou une vraie question?
Parce que bon… -
La version lorraine est une des meilleure.
Pour faire de l’administration serveur j’imagine qu’il n’y a aucune différence avec Putty mais dans les de transferts importants de données on a des chiffres de comparaison ? Il ne fonctionne qu’en udp ? -
Nope pas de chiffres sous la main @Raccoon
Mais le protocole Quick semble avoir fait ses preuves.QUIC est un protocole expérimental, créé par le moteur de recherche Google et présenté au public en 2013. Le nom signifie « Quick UDP Internet Connections » (connexions Internet UDP rapides), car il permet l’envoi rapide de paquets simples via le protocole UDP (User Datagram Protocol) sans connexion. La raison du développement de QUIC était le désir de fournir une alternative aux solutions de sécurité TCP, HTTP/2 et TLS/SSL en développant la même protection mais avec un délai de connexion et de transport réduit, et en permettant des connexions de multiplexage.
-
@Violence a dit dans [Linux Apps] Quicssh : booster vos connexions SSH :
@Snoubi a dit dans [Linux Apps] Quicssh : booster vos connexions SSH :
sinon ya putty non c’est du même accabi ? Merci pour le post
Euhh c’est du troll ou une vraie question?
Parce que bon…parce que bon quoi c’est une question ya que des réponse troll j’ai l’impression
-
Sorry, mais parce que la réponse est dans l’article.
Pour ceux qui ne le savent pas, QUIC est un protocole de transport
Tout comme SSH.
Putty n’est qu’une application et non un protocole, donc elle ne peut être du même acabit. -
bah c’est une appli github non ?
-
@Snoubi on te l’a fait pas à toi.
-
La question est de savoir si un client SSH qui gère QUIC existe sur Windows.
L’échange des données sur Internet se fait via des protocoles de communication qui sont regroupés dans des groupes : TPC/IP et OSI. Chacun ont leurs avantages et inconvénients : https://www.pierre-giraud.com/http-reseau-securite-cours/modele-reseau-osi-tcp-ip/
Quand tu te connectes en SSH, de manière simple comme on le fait tous via un Terminal ou un client dédié, tu utilises TCP avec la surcouche TLS de sécurité. Même principe quand tu navigues sur Internet sur des sites httpS.
(en gros) Le modèle QUIC est plus léger que TCP+TLS, il est donc plus rapide : https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html
Et la rapidité, la plus faible latence, est juste indispensable de nos jours pour toutes les communications réseau. Le modèle actuel TCP+TLS, implémenté sur tous les appareils (serveurs, routeurs etc) ne peut pas évoluer lui-même, il fallait en créer un autre.QUIC passe par UDP pour info. Et pour ceux qui veulent en savoir un peu plus je vous recommande de chercher http/3.
-
Merci pour la brève explication Aerya
-
Pour les monos langage (dans mon genre )
https://www.fasterize.com/fr/protocole-http3-changements-http1-http2/
-
Avez vous tester ?
Je me demande a quel point c’est plus performant. J’ai du mal a comprendre comment le fait de mettre un proxy accelere le transfert. passera par ssh quoi qu’il arrive -
@Nymeria si j’ai bien compris, c’est au niveau du transport réseau que se font les gains et non pas au niveau des ordinateurs.
QUIC optimise le transfert des données, car les protocoles TCP+TLS sont assez lents.
Ce qui dérangait au départ, c’étatit que c’était un truc Google… Mais, maintenant, comme Quic est défini dans le RFC9000, il est implémentable par n’importe qui - sans avoir besoin de l’aval de (l’orgre Google.
-
j’aurais une question (bête, sûrement…) ; quelqu’un qui utilise SSH sans quic peut-il tout de même communiquer avec un ordinateur distant fonctionnant sous le protocole quic ? Merci de m’éclairer, car ça me semble un peu flou cette histoire…
-
@Rapace malheureusement je n’ai pas encore pu tester… mais en lisant les docs de “moul/quicssh” la connection quic se fait sur des ports différents de ceux de ssh (normalement 22). Donc, oui en utilisant un client ssh “normal”, ce dernier va se connecter directement au port 22 du serveur distant sans passer par proxy-quic (côté serveur).
pour utiliser le proxy quicssh, un client ssh se connecte localement sur le port du proxy-quic (côté client) et c’est ce dernier qui va se connecter au proxy-quic (côté serveur). Ensuite ce dernier va se connecter “normalement” au ssh port 22
C’est ce que j’ai compris des docs… si qqn comprend mieux ou peux expliquer plus facilement - je suis preneur !
PS: les dessins du premeir post sont clairs
-
Désolé pour le HS, je ne peux pas résister à relever le “moule/quiche” comme nom de protocole…