Existe-t-il un moyen d’éviter les retards de frappe SSH?

Puis-je dire à SSH d’envoyer les données uniquement après avoir appuyé sur Entrée ou sur la touche de tabulation, et non après chaque pression sur une touche?

Non, car SSH n'a aucun moyen de savoir si ce que vous tapez nécessiterait une action ou une tabulation - si vous essayez de consulter l'historique de vos commandes, par exemple, les ^Rflèches vers le haut ou vers le haut ne seront pas envoyées par eux-mêmes, et ce serait ... désagréable.

Vous n'avez pas besoin d'attendre entre chaque caractère pour qu'il apparaisse à l'écran, cependant; si vous savez ce que vous devez taper, écrivez-le aussi vite que vous le souhaitez, et le terminal vous rattrapera dans environ un aller-retour à partir du moment où vous avez arrêté de taper, ce qui est à peu près aussi efficace que vous en sortirez. de toute façon, une configuration avec tampon de ligne (la perte de paquet est différente, mais elle introduit ses propres bizarreries intéressantes).

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

PuTTY propose également d'autres options pour activer / désactiver certains éléments (algorithme de Nagle) susceptibles d'affecter la latence perçue des connexions. À mes yeux, le client OpenSSH n'offre pas toutes les fonctionnalités proposées par PuTTY à cet égard, et je ne connais pas d'alternative Linux comparable.

Sinon, Womble a raison.

Mosh a été conçu pour résoudre ce problème. Il est conçu pour une utilisation sur des connexions à latence élevée et peu fiables, et fournit un montage d'écho et de ligne local.

Ouvrez la session ssh avec ssh host.example.org bash(ou le shell que vous voulez utiliser).

Vous obtiendrez le mode ligne tamponné sur le shell distant, ce qui signifie que vous ne recevrez pas d'invite ni de modification de ligne, mais que vous obtiendrez un écho local et le mode "une ligne à la fois". C'est parfois utile lorsque vous travaillez 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:

Lorsque vous utilisez l'astuce ci-dessus, vous pouvez obtenir une édition de ligne normale ( readline ) au niveau local en utilisant un programme d'encapsulation très pratique appelé rlfe . Il suffit de courir rlfe ssh host.example.org bash.

Ayant eu le même problème ( latence élevée et la perte de paquets en raison de la qualité terrible de données mobiles à certains endroits), et Mosh ne coupe pas pour moi (il a besoin de programmes spéciaux sur tous les hôtes distants, fixer UTF8 localement et à distance sans les briser sur tous les serveurs , en modifiant tous les pare-feu - et il ne fournit pas vraiment l'édition de ligne locale) J'ai décidé d'écrire un petit wrapper pour fournir le mode d'édition de ligne locale pour ssh .

Par défaut, il transmet simplement tout à ssh en mode caractère par caractère, mais vous pouvez appuyer sur un raccourci clavier pour passer à tout moment en mode de modification de ligne locale alimenté par readline. Ainsi, vous pouvez entrer (avec édition, rappel de commande, etc.) en ligne entière, puis lorsque vous appuyez sur Entrée, elle sera envoyée sous la forme d'un paquet TCP au côté distant.

Advantage est une édition de ligne de commande sans décalage (comme l’ancien "mode de mise en tampon ligne à ligne", telle que cuite / canonique de telnet, mais avec des commandes d’édition supérieures fournies par GNU readline ). De plus, rien ne doit être changé sur les serveurs ou les pare-feu. Et les éditeurs et autres programmes basés sur curses continuent de fonctionner normalement (avec retard cependant) en mode caractère par caractère comme dans la connexion ssh normale.

L’inconvénient est que vous devez soit appuyer sur la touche de raccourci pour passer en mode d’édition de ligne locale chaque fois que vous le souhaitez, soit modifier l’invite sur un hôte distant pour permettre la détection automatique. De plus, l' achèvement de nom de fichier par onglet distant ne fonctionne actuellement qu'en vous ramenant au mode caractère par caractère (ou en utilisant un système de fichiers local au lieu d'un système distant, selon vos préférences). C'est un travail en cours, cependant, les demandes de propositions ou les idées réalisables d'amélioration sont les bienvenues!

L’avantage, c’est non seulement que votre shell (et son édition de ligne) est local et sans décalage, mais vous pouvez également naviguer dans le système de fichiers distant et utiliser la complétion du nom de fichier du shell ( touche de tabulation ) pour les fichiers distants. En outre, (la meilleure fonctionnalité à mon humble avis), vous pouvez utiliser l’éditeur local de votre choix pour une édition sans décalage des fichiers distants.

Les inconvénients sont (surtout si votre lien est également à faible bande passante et pas seulement à latence élevée) que pour chaque fichier à modifier, il doit être intégralement transféré sur localhost, puis intégralement transféré à distance sur un fichier distant. SSHFS ne prévoit une mise en cache (voir SSHFS (1) Options cache , cache_timeout , cache_x_timeout pour atténuer les problèmes que peu). De plus, si vous voulez exécuter quelque chose sur remote, 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 dans ssh_config (5) pour accélérer l'exécution (sans invite de mot de passe).

Vous pouvez émuler ce comportement si vous n'exécutez que des commandes en faisant,

utilisateur ssh @ targetmachine 'mes commandes dans une chaîne'

mais,

1. cela ajoute un délai supplémentaire dans la création de la connexion (peut être atténué en utilisant des connexions ssh maître / partagées )
2. si vous n'avez pas de clé privée sans mot de passe, vous devrez utiliser ssh-agentou taper le mot de passe
3. il est évident que cela ne fonctionne pas si vous interagissez avec des menus, modifiez des fichiers, etc.

Vous pouvez utiliser tmux pour obtenir un écho fluide de votre frappe. Exécutez tmux localement. Si vous avez le shell ssh dans un volet et un shell local dans un volet situé en dessous, vous pouvez envoyer des clés dans le volet distant à partir du volet local.

tmux send-keys -t top 'ls' C-m

Commandes interactives et petites commandes que je tape directement dans le shell ssh en retard. Dès que le décalage commence à gêner ma saisie, je bascule vers le volet local et utilise les touches d'envoi. Cela fonctionne même lorsque vous tapez une commande.

Pour le raccourcir j'ai ajouté ceci à mon .bashrc

function ts {
    args=$@
    tmux send-keys -t right "$args" C-m
}

Merci à Christian Pelczarski pour avoir expliqué les clés d'envoi: https://minimul.com/increased-developer-productivity-with-tmux-part-5.html

Vous devrez vous échapper lorsque vous utilisez des guillemets, par exemple

ts git config --global alias.lola \'log --graph --decorate --pretty=oneline --abbrev-commit --all\'

Cela fait ce que tu veux. Vous devez cependant installer le client et le serveur, et OpenSSH en amont n'a jamais adopté les modifications. https://github.com/hyc/OpenSSH-LINEMODE