Tendo o mesmo problema ( alta latência e perda de pacotes devido à péssima qualidade de dados móveis em alguns locais), e mosh não o corta para mim (ele precisa de programas especiais em todos os hosts remotos, consertando o UTF8 local e remotamente em todos os servidores sem quebrá-los, modificando todos os firewalls - e isso realmente não fornece edição de linha local de qualquer maneira) Eu decidi escrever um pequeno wrapper para fornecer modo de edição de linha local para ssh .
Por padrão, ele passa tudo para ssh no modo padrão char-by-char, mas você pode pressionar uma tecla de atalho para entrar no modo de edição de linha local alimentado por readline a qualquer momento. Assim, você poderia inserir (com edição, comando de recall, etc) toda a linha localmente e, em seguida, quando você pressionar digite , ele será enviado como um pacote TCP para o lado remoto.
A vantagem é a edição de linha de comando livre de atraso (como o antigo modo de buffer line-by-line telnet cozido / canônico ", mas com comandos de edição superiores fornecidos por linha de leitura GNU ). Além disso, nada precisa ser alterado em servidores ou firewalls. E os editores e outros programas baseados em curses continuam a funcionar normalmente (embora com atraso) no modo padrão char-by-char como na conexão ssh normal.
A desvantagem é que você precisa pressionar a tecla de atalho para entrar no modo de edição de linha local toda vez que quiser, ou precisa modificar o prompt no host remoto para permitir a autodetecção. Além disso, a conclusão do nome do arquivo remoto atualmente funciona apenas com a remoção do modo char-by-char (ou usa o sistema de arquivos local em vez do remoto, dependendo de suas preferências). No entanto, é um trabalho em andamento, portanto, solicitações de pedidos ou ideias viáveis para melhoria são bem-vindas!
Do lado não convencional, você poderia alternativamente usar o
SSHFS para montar o sistema de arquivos remoto localmente.
A vantagem não é apenas que seu shell (e sua edição de linha) é local e livre de atrasos, mas também que você pode navegar pelo sistema de arquivos remoto e usar a conclusão do nome do shell ( tecla ) para remoto arquivos. Além disso, (o melhor recurso IMHO) você pode usar o editor local de escolha para a edição de arquivos remotos sem lag.
As desvantagens são (especialmente se você vincular também baixa largura de banda, e não apenas alta latência) que para cada arquivo a ser editado, ele precisa ser totalmente transferido para localhost e depois de editar, totalmente transferido para remoto novamente . O SSHFS fornece algum armazenamento em cache (consulte as opções sshfs (1) cache , cache_timeout , cache_x_timeout ) para aliviar um pouco os problemas.
Além disso, se você quiser executar algo no remoto, precisará usar outra tela ou prefixar todos os comandos com " ssh remotehost " (por exemplo, ssh remotehost sudo service apache restart ). Veja a opção ControlMaster em ssh_config (5) para agilizar a execução (e sem solicitação de senha).