Existe-t-il un moyen d'éviter le délai de saisie de SSH ?

Mosh a été conçu pour répondre à ce problème précis. Il est conçu pour être utilisé sur des connexions à forte latence et peu fiables, et fournit un écho local et une édition de ligne.

PuTTY offre deux fonctions qui peuvent être utiles : "écho local" et "édition de ligne locale". L'édition de ligne locale met tout en mémoire tampon et ne l'envoie au serveur qu'après un retour à la ligne. Cela peut rendre la ligne de commande beaucoup plus facile à gérer, mais cela peut aussi rendre l'utilisation d'un éditeur de texte infernale.

PuTTY dispose également d'autres options pour activer/désactiver certains éléments (algorithme de Nagle) qui peuvent affecter la latence de connexion perçue. À mon avis, le client OpenSSH n'offre pas toutes les fonctionnalités de PuTTY à cet égard, et je ne connais pas d'alternative Linux comparable.

Sinon, Womble a raison.

Ouvrez la session ssh avec ssh host.example.org bash (ou tout autre Shell que vous voulez utiliser).

Vous obtiendrez le mode tampon de ligne vers le Shell distant, ce qui signifie que vous n'obtiendrez pas d'invite et d'édition de ligne, mais vous obtiendrez l'écho local et le mode "une ligne à la fois". C'est parfois utile lorsque l'on travaille avec une très mauvaise connexion. Tous les programmes ne fonctionneront pas correctement car vous n'aurez pas de pseudo-tty mais la plupart des utilitaires UNIX fonctionnent parfaitement.

Mise à jour :

En utilisant l'astuce ci-dessus, vous pouvez obtenir une édition de ligne normale ( ligne de lecture ) au local en utilisant un programme d'enveloppe pratique appelé rlfe . Il suffit de courir rlfe ssh host.example.org bash .

Ayant eu le même problème ( latence élevée et perte de paquets en raison de la mauvaise qualité des données mobiles à certains endroits), et mosh ne me convient pas (il faut des programmes spéciaux sur tous les hôtes distants, fixer UTF8 localement et à distance sur tous les serveurs sans les casser, modifier tous les pare-feu - et il ne fournit pas vraiment d'édition de ligne locale de toute façon), j'ai décidé d'écrire un petit wrapper qui fournit mode d'édition de ligne locale pour ssh .

Par défaut, il transmet tout à ssh en mode char par char, mais vous pouvez appuyer sur une touche de raccourci pour entrer à tout moment dans le mode d'édition locale de la ligne de lecture. Ainsi, vous pouvez entrer (avec édition, rappel de commande, etc.) une ligne entière localement, puis lorsque vous appuyez sur entrez il sera envoyé comme un paquet TCP au côté distant.

L'avantage est l'édition de la ligne de commande sans décalage (comme l'ancien telnet cuit/canonique "mode tampon ligne par ligne", mais avec des commandes d'édition supérieures fournies par GNU readline ). De même, rien ne doit être modifié sur les serveurs ou les pare-feu. Et les éditeurs et autres programmes basés sur curses continuent de fonctionner normalement (bien qu'avec un décalage) en mode char-par-char par défaut comme dans une connexion ssh normale.

L'inconvénient est que vous devez soit appuyer sur un raccourci pour entrer dans le mode d'édition de ligne local chaque fois que vous le voulez, soit modifier l'invite sur l'hôte distant pour permettre l'autodétection. De plus, le serveur distant onglet La complétion des noms de fichiers ne fonctionne actuellement qu'en vous ramenant au mode char par char (ou utilise le système de fichiers local au lieu du système distant, selon vos préférences). C'est un travail en cours, cependant, donc les demandes d'améliorations ou les idées réalisables sont les bienvenues !

Du côté non conventionnel, vous pourriez utiliser alternativement SSHFS pour monter localement le système de fichiers distant.

L'avantage est non seulement que votre Shell (et son édition de ligne) est locale et sans décalage, mais aussi que vous pouvez naviguer dans le système de fichiers distant et utiliser la complétion de nom de fichier de Shell ( touche de tabulation ) pour les fichiers distants. De plus, (la meilleure caractéristique, selon moi) vous pouvez utiliser votre éditeur local de choix pour éditer sans délai les fichiers distants.

Les inconvénients sont (surtout si votre lien est également à faible bande passante, et pas seulement à haute latence) que pour chaque fichier à éditer, il doit être entièrement transféré à l'hôte local, puis après l'édition, entièrement transféré à nouveau à distance. SSHFS prévoit une certaine mise en cache (voir les options de sshfs(1)) cache , cache_timeout , cache_x_timeout ) pour atténuer quelque peu ce problème. De plus, si vous voulez exécuter quelque chose à distance, vous devez utiliser un autre écran ou préfixer toutes les commandes avec " ssh remotehost "(par exemple ssh remotehost sudo service apache restart ). Voir l'option ControlMaster sur ssh_config(5) pour rendre l'exécution plus rapide (et sans demande de mot de passe).