Mosh

Q : Qui a écrit Mosh ?

Mosh a été écrit par Keith Winstein, avec Anders Kaseorg, Quentin Smith, Richard Tibbetts, Keegan McAllister et John Hood.

Q : Pourquoi un autre protocole de terminal distant ?

La latence pratique sur Internet est en augmentation, avec la montée du bufferbloat et des liaisons sans fil sophistiquées qui optimisent le débit par rapport au retard. Et l’itinérance est plus courante que jamais, maintenant que les ordinateurs portables et les appareils de poche ont largement remplacé les ordinateurs de bureau. SSH est génial, mais frustrant à utiliser lorsque vous voulez changer d’adresse IP ou que vous avez un lien à long délai ou une connexion douteuse.

De plus, TELNET avait quelques bonnes choses à son actif – un mode écho local et un terminal virtuel réseau bien défini. Même aujourd’hui, SSH ne supporte pas correctement UTF-8 de bout en bout sur un système POSIX.

Q : Les principes de mosh sont-ils pertinents pour d’autres applications réseau ?

Nous pensons que oui. Les principes de conception que défend Mosh sont conservateurs : avertir l’utilisateur si l’état affiché est périmé, sérialiser et checkpointer toutes les transactions de sorte que, s’il n’y a pas d’avertissement, l’utilisateur sait que chaque transaction antérieure a réussi, et gérer les événements attendus (comme l’itinérance d’un réseau WiFi à un autre) de manière gracieuse.

Ceux-ci ne semblent pas trop controversés, mais les applications fantaisistes comme Gmail-in-Chromium ou sur Android se comportent toujours de manière atroce sur des connexions douteuses ou après avoir changé d’adresse IP. (Avez-vous déjà vu Gmail laisser un message électronique dans « Sending… » pendant dix heures alors qu’il récupérait joyeusement de nouveaux messages sans indiquer aucune sorte d’erreur ? Nous aussi). Nous pensons qu’il peut y avoir une marge d’amélioration considérable dans de nombreuses interfaces utilisateur réseau à partir de l’application de ces valeurs.

Q : Je reçois « mosh exige une locale UTF-8. » Comment puis-je corriger cela ?

Pour diagnostiquer le problème, exécutez locale sur le terminal local, et ssh remotehost locale. Pour utiliser Mosh, les deux côtés de la connexion devront afficher une locale UTF-8, comme LC_CTYPE="en_US.UTF-8".

Sur de nombreux systèmes, SSH transférera les variables d’environnement liées à la locale, qui sont ensuite héritées par mosh-server. Si ce mécanisme échoue, Mosh (à partir de la version 1.2) transmettra lui-même les variables. Si aucun des deux mécanismes ne réussit, vous pouvez faire quelque chose comme

mosh remotehost --server="LANG=en_US.UTF-8 mosh-server"

Si en_US.UTF-8 n’existe pas sur le serveur distant, vous pouvez le remplacer par une locale UTF-8 qui existe. Vous devrez peut-être aussi définir LANG localement pour bénéficier de mosh-client. Il est possible que les machines locales et distantes aient besoin de noms de locale différents. Voir aussi ce ticket GitHub.

Q : Que signifie le message « Rien reçu du serveur sur le port UDP 60003 » ?

Cela signifie que mosh a pu démarrer mosh-server avec succès sur la machine distante, mais que le client n’est pas en mesure de communiquer avec le serveur. Cela signifie généralement qu’un certain type de pare-feu bloque les paquets UDP entre le client et le serveur. Si vous avez dû transférer le port TCP 22 sur un NAT pour SSH, vous devrez également transférer les ports UDP. Mosh utilisera le premier port UDP disponible, en commençant par 60001 et en s’arrêtant à 60999. Si vous n’allez avoir qu’une petite poignée de sessions simultanées sur un serveur, alors vous pouvez transférer une plus petite plage de ports (par exemple, 60000 à 60010).

Des outils comme netstat, netcat, socat et tcpdump peuvent être utiles pour déboguer les problèmes de réseau et de pare-feu.

Ce problème peut également être le résultat d’un bogue dans la glibc 2.22 qui affecte les programmes qui se lient avec protobuf et utempter et utilisent des drapeaux agressifs de durcissement du compilateur. (entrée du bugtracker de la glibc, ainsi que l’entrée du bugtracker de Mosh.) Le problème fait que mosh-server se met en défaut immédiatement au démarrage. Nous pensons avoir résolu ce problème dans Mosh 1.2.6, mais veuillez signaler un bogue si vous trouvez le contraire.

Q : Pourquoi insistez-vous sur UTF-8 partout ?

Nous ne sommes vraiment pas des fanatiques de l’UTF-8. Mais il est beaucoup plus facile d’implémenter correctement un émulateur de terminal que d’essayer de faire la bonne chose dans une variété de cas limites difficiles. (C’est ce que GNU screen essaie de faire, et d’après notre expérience, cela conduit à des situations très délicates à déboguer). Ainsi, mosh ne démarrera pas tant que l’utilisateur n’aura pas tout configuré pour une voie sans UTF-8. C’est peut-être ennuyeux, mais cela réduit probablement les frustrations sur la route. (Malheureusement, un vt220 8 bits et un vt220 UTF-8 sont des types de terminaux différents et incompatibles ; l’UTF-8 va en dessous de la machine d’état vt220.)

Q : Comment puis-je utiliser un port SSH différent (pas 22) ?

A compter de Mosh 1.2, vous pouvez passer des arguments à ssh comme ceci :

mosh remotehost --ssh="ssh -p 2222"

Ou configurer un alias d’hôte dans ~/.ssh/config avec une directive Port. Mosh respectera cela aussi.

Q : Je reçois ‘mosh-server not found’.

Veuillez vous assurer que mosh est installé sur le client, et que mosh (ou au moins mosh-server) est installé sur le serveur auquel vous essayez de vous connecter. En outre, le serveur est censé être disponible sur le login par défaut de votre serveur PATH, ce qui n’est généralement pas vrai sur les serveurs OS X et BSD, ou si vous installez mosh-server dans votre répertoire personnel. Dans ces cas, veuillez consulter les instructions « Server binary outside path » dans la section Utilisation, ci-dessus.

Q : SSH s’authentifie à l’aide de tickets Kerberos, mais Mosh me demande un mot de passe.

Dans certaines configurations, SSH canonise le nom d’hôte avant de le transmettre au plugin Kerberos GSSAPI. Cela casse pour Mosh, car la recherche initiale de DNS en avant est effectuée par le script wrapper de Mosh. Pour contourner ce problème, invoquez Mosh as

mosh remotehost --ssh="ssh -o GSSAPITrustDns=no"

Ceci échouera souvent sur une configuration DNS round-robin. Dans ce cas, il est probablement préférable de choisir un hôte spécifique dans le pool round-robin.

Q : Pourquoi le tampon de défilement de mon terminal est-il incomplet ?

Mosh ne synchronise que l’état visible du terminal. Nous suivons ce problème ; voir ce problème et les autres qui sont liés à partir de là. Pour l’instant, la solution de contournement consiste à utiliser screen ou tmux du côté distant.

Q : Comment puis-je obtenir 256 couleurs ?

Veuillez vous assurer que vous exécutez mosh dans un terminal qui s’annonce comme capable d’afficher 256 couleurs. (Cela signifie généralement que TERM sera xterm-256color ou screen-256color-bce.)

Q : Comment taper C-^, le caractère d’échappement par défaut de Mosh ?

Sur les claviers avec la disposition américaine, cela peut être tapé comme Ctrl-Shift-6, ou souvent comme Ctrl-6 (cela dépend de votre OS et de votre émulateur de terminal). Sur les claviers non américains, il est souvent difficile de trouver la bonne touche, et parfois elle n’est pas disponible du tout. Si votre clavier comporte une touche morte avec un accent circonflexe, il est peu probable que ce soit la bonne touche. Ctrl-6 fonctionne parfois. Si vous ne pouvez pas taper ce caractère, vous devrez définir la variable MOSH_ESCAPE_KEY ; consultez la page de manuel Mosh pour plus de détails.

Q : Comment puis-je faire en sorte que le serveur nettoie automatiquement les sessions dormantes ?

Veuillez consulter les entrées pour MOSH_SERVER_NETWORK_TMOUT et MOSH_SERVER_SIGNAL_TMOUT dans la page man de mosh-server(1).

Q : Quel est le bilan de sécurité de Mosh jusqu’à présent ?

Mosh 1.0 a été publié en mars 2012. Depuis la publication de Mosh 1.3.2 en juillet 2017, à la connaissance des développeurs :

• Au cours des quatre dernières années, aucune vulnérabilité de sécurité de quelque nature que ce soit (majeure ou mineure) n’a été signalée dans Mosh.
• Aucune vulnérabilité de sécurité majeure n’a jamais été signalée dans Mosh. Nous définissons les vulnérabilités de sécurité majeures comme l’escalade de privilèges, l’exécution de code à distance, le déni de service par un tiers, etc.
• Deux problèmes de déni de service ont été découverts et corrigés dans les versions de 2012. Un problème permettait à un mosh-server d’amener themosh-client à dépenser un excès de CPU (CVE-2012-2385, corrigé dans Mosh1.2.1, publié en mai 2012). Un autre problème permettait au serveur-hôte d’amener le mosh-client à envoyer des datagrammes UDP à une adresse incorrecte, faisant échouer sa tentative de connexion (corrigé dansMosh 1.2.3, publié en octobre 2012).

Q : Comment la sécurité de Mosh se compare-t-elle à celle de SSH ?

Nous pensons que la conception conservatrice de Mosh signifie que sa surface d’attaque se compare favorablement avec des systèmes plus compliqués comme OpenSSL et OpenSSH. L’historique de Mosh a jusqu’à présent confirmé cette hypothèse. En fin de compte, cependant, seul le temps dira quand la première vulnérabilité sérieuse de sécurité sera découverte dans Mosh – soit parce qu’elle était là depuis le début, soit parce qu’elle a été ajoutée par inadvertance au cours du développement. OpenSSH et OpenSSL ont eu plus de vulnérabilités, mais ils ont également été publiés plus longtemps et sont plus répandus.

Dans un aspect concret, le protocole Mosh est plus sûr que celui de SSH : SSH s’appuie sur un TCP non authentifié pour transporter le contenu du flux sécurisé. Cela signifie qu’un attaquant peut mettre fin à une connexion SSH avec un seul segment « RST » bidon. En revanche, Mosh applique sa sécurité à une couche différente (en authentifiant chaque datagramme), de sorte qu’un attaquant ne peut pas mettre fin à une session Mosh à moins qu’il ne puisse empêcher en permanence les paquets d’atteindre l’autre côté. Un attaquant transitoire ne peut causer qu’une panne transitoire visible par l’utilisateur ; une fois l’attaquant parti, Mosh reprendra la session.

Cependant, dans une utilisation typique, Mosh s’appuie sur SSH pour échanger des clés au début d’une session, donc Mosh héritera des faiblesses de SSH – au moins dans la mesure où elles affectent la brève session SSH qui est utilisée pour configurer une session Mosh de longue durée.

Q : Mosh est-il affecté par les attaques de 2018 contre le mode de chiffrement OCB2 ?

Pas à notre connaissance – Mosh utilise le mode de chiffrement OCB3. Les auteurs du papier écrivent que l’attaque n’est pas applicable à OCB3.

Q : Pourquoi mosh utilise-t-il AES-128 pour une clé de session, et non AES-192 ou AES-256 ?

• L’AES-128 est une longueur de clé plus qu’adéquate pour une clé de session.
• La FAQ OCB recommande l’AES-128.
• L’AES-128 est un peu plus joli et n’est pas sujet aux attaques de clés connexes qui affligent l’AES-192 et l’AES-256. (Schneier : « le calendrier des clés pour la version 256 bits est assez minable — ce que nous avons souligné dans notre article de 2000 — mais ne s’étend pas à l’AES avec une clé de 128 bits. » Voir ce billet de blogue.)

Q : Est-ce que mosh fonctionne avec Amazon EC2 ?

Oui, il fonctionne très bien, mais n’oubliez pas d’ouvrir les ports UDP 60000-61000 sur le pare-feu EC2.

Q : Comment puis-je savoir si mosh fonctionne correctement ?

Après avoir exécuté mosh user@server, en cas de succès, vous serez déposé dans votre shell de connexion sur la machine distante. Si vous voulez vérifier que mosh est utilisé au lieu de ssh, essayez de taper Ctrl-^ Ctrl-Z pour suspendre la session (avec mosh 1.2.4 ou plus sur le client). L’exécution de fg renverra alors.

Q : Quelle est la différence entre mosh, mosh-client et mosh-server ? Lequel dois-je utiliser ?

La commande mosh est un script d’emballage qui est conçu pour être la façon principale dont vous utilisez mosh. Dans la plupart des cas, vous pouvez simplement remplacer « ssh » par « mosh » dans votre ligne de commande. En coulisse, le script mosh wrapper va se connecter en SSH au serveur, démarrer mosh-server, puis fermer la connexion SSH. Ensuite, il lancera l’exécutable mosh-client sur le client, lui transmettant les informations nécessaires pour qu’il se connecte à l’instance mosh-server nouvellement créée.

Dans une utilisation normale, mosh-client et mosh-server n’ont pas besoin d’être exécutés directement.

Q : Comment puis-je exécuter le client et le serveur mosh séparément ?

Si le script wrapper mosh ne fonctionne pas pour vous, vous pouvez essayer d’exécuter les programmes mosh-client et mosh-server séparément pour former une connexion. Cela peut être une technique de débogage utile.

1. Connectez-vous à l’hôte distant, et exécutez mosh-server.

Il donnera une sortie comme:

$ mosh-server MOSH CONNECT 60004 4NeCCgvZFe2RnPgrcU1PQwmosh-server (mosh 1.1.3)Copyright 2012 Keith Winstein <[email protected]>License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.

2. Sur l’hôte local, exécutez :

$ MOSH_KEY=key mosh-client remote-IP remote-PORT

où « key » est la chaîne de 22 octets imprimée par mosh-server (dans cet exemple, « 4NeCCgvZFe2RnPgrcU1PQw »), « remote-PORT » est le numéro de port donné par le serveur (60004 dans ce cas), et « remote-IP » est l’adresse IP du serveur. Vous pouvez rechercher l’adresse IP du serveur avec « host remotehost ».

3. Si tout va bien, vous devriez avoir une connexion Mosh fonctionnelle. Les informations sur les endroits où le processus échoue peuvent nous aider à déboguer la raison pour laquelle Mosh ne fonctionne pas pour vous.

Q : Avec le serveur mosh sur FreeBSD ou OS X, j’ai parfois des problèmes de couleurs bizarres. Quel est le problème ?

Ce bogue est corrigé dans Mosh 1.2. Merci à Ed Schouten et Peter Jeremy pour l’avoir repéré.

Q : Comment puis-je contribuer à mosh ?

Nous accueillons votre contribution ! Veuillez nous rejoindre dans le canal #mosh sur Freenode IRC, visitez-nous sur GitHub, ou envoyez un courriel à [email protected]. Pour contribuer à notre base de code, veuillez forker le dépôt sur GitHub et y ouvrir une demande de pull.

Q : Qui a aidé à mosh ?

Nous sommes très reconnaissants pour l’aide et le soutien de :

• Hari Balakrishnan, qui a conseillé ce travail et a trouvé le nom.
• Paul Williams, dont le diagramme d’état vt500 en ingénierie inverse est la base de l’analyseur syntaxique Mosh.
• Les utilisateurs anonymes qui ont contribué aux journaux de session pour le réglage et la mesure de l’écho prédictif de Mosh.
• Nickolai Zeldovich pour des commentaires utiles sur le document de recherche de Mosh.
• Richard Stallman pour une discussion utile sur les capacités du protocole d’édition locale SUPDUP.
• Nelson Elhage
• Christine Spang
• Stefie Tellex
• Joseph Sokol-Margolis
• Waseem Daher
• Bill McCloskey
• Austin Roach
• Greg Hudson
• Karl Ramm
• Alexander Chernyakhovsky
• Peter Ianneton
• .
• Peter Iannucci
• Evan Broder
• Neha Narula
• Katrina LaCurts
• Ramesh Chandra
• Peter Jeremy
• Ed Schouten
• Ryan Steinmetz
• Jay Freeman
• Dave Täht
• Larry Doolittle
• Daniel Drown
• Timo Juhani Lindfors
• Timo Sirainen
• Ira Cooper
• Felix Gröbert
• Luke Mewburn
• Anton Lundin
• Philipp Haselwarter
• Timo J. Rinne
• Barosl Lee
• Andrew Chin
• Louis Kruger
• Jérémie Courrèges-Anglas
• Pasi Sjöholm
• Richard Woodbury
• Igor Bukanov
• Geoffrey Thomas
• Steve Dignam
• HIGUCHI Yuta
• Baruch Siach

.