Existe uma maneira de evitar o atraso na digitação do SSH?

Posso dizer ao SSH para enviar os dados somente depois de pressionar enter ou tab e não depois de cada pressionamento de tecla individual?

Não, porque o SSH não tem como saber se o que você está digitando exigiria uma entrada ou guia para ação - se você estiver tentando passar por seu histórico de comandos, por exemplo, as ^Rsetas para cima ou para cima não serão enviadas por eles mesmos, e isso seria ... desagradável.

Você não precisa esperar entre cada personagem para que ele apareça na tela; se você souber o que precisa digitar, faça o rápido que quiser, e o terminal alcançará cerca de um tempo de ida e volta a partir do momento em que você parou de digitar, o que é tão bom quanto você uma configuração com buffer de linha de qualquer maneira (a perda de pacotes é diferente, mas apresenta suas próprias peculiaridades).

O PuTTY oferece dois recursos que podem ser úteis: "eco local" e "edição de linha local". A edição de linha local armazena tudo em buffer e o envia somente ao servidor após o retorno da linha. Isso pode tornar a linha de comando muito mais fácil de lidar, mas também pode facilitar o uso de um editor de texto.

O PuTTY também possui outras opções para ativar / desativar certas coisas (algoritmo de Nagle) que podem afetar a latência percebida da conexão. A meu ver, o cliente OpenSSH não oferece todos os recursos que o PuTTY oferece a esse respeito, e não conheço uma alternativa Linux que se compare.

Caso contrário, womble está certo.

Mosh foi projetado para resolver esse problema exato. Ele foi projetado para uso em conexões de alta latência e não confiáveis ​​e fornece eco local e edição de linha.

Abra a sessão ssh com ssh host.example.org bash(ou qualquer shell que você deseja usar).

Você obterá o modo de buffer de linha no shell remoto, o que significa que você não receberá um prompt e a edição de linha, mas o eco local e o modo "uma linha por vez". Às vezes, é útil quando se trabalha com uma conexão muito ruim. Nem todos os programas serão executados corretamente porque você não terá uma pseudo-tty, mas a maioria dos utilitários UNIX funciona bem.

Atualizar:

Ao usar o truque acima, você pode obter a edição de linha normal (linha de leitura ) no final local , usando um programa de wrapper conveniente chamado rlfe . Apenas corra rlfe ssh host.example.org bash.

Tendo o mesmo problema ( alta latência e perda de pacotes devido à péssima qualidade dos dados móveis em alguns locais), e o mosh não o resolve para mim (ele precisa de programas especiais em todos os hosts remotos, corrigindo o UTF8 local e remotamente em todos os servidores sem quebrá-los , modificando todos os firewalls - e realmente não fornece edição de linha local) Decidi escrever um pequeno invólucro para fornecer o modo de edição de linha local para ssh .

Por padrão, ele passa tudo para ssh no modo padrão de caractere por caractere, mas você pode pressionar uma tecla de atalho para entrar no modo de edição de linha local com linha de leitura a qualquer momento. Assim, você pode inserir (com edição, recuperação de comandos, etc) toda a linha localmente e, ao pressionar enter, ela será enviada como um pacote TCP para o lado remoto.

A vantagem é a edição de linha de comando sem atraso (como o antigo "modo buffer linha a linha" cozido / telnet, mas com comandos de edição superiores fornecidos pela linha de leitura GNU ). Além disso, nada precisa ser alterado em servidores ou firewalls. E editores e outros programas baseados em maldições continuam funcionando normalmente (embora com lag) no modo char-by-char padrão 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 desejar, ou modificar o prompt no host remoto para permitir a detecção automática. Além disso, a conclusão do nome do arquivo da guia remota atualmente funciona apenas retornando ao modo char a char (ou usa o sistema de arquivos local em vez do remoto, dependendo das suas preferências). No entanto, é um trabalho em andamento; portanto, solicitações de recebimento ou idéias viáveis ​​de melhoria são bem-vindas!

A vantagem não é apenas que seu shell (e sua edição de linha) é local e sem lag, mas também que você pode navegar pelo sistema de arquivos remoto e usar a conclusão do nome do arquivo do shell ( tecla tab ) para arquivos remotos. Além disso, (o melhor recurso IMHO), você pode usar o editor local de sua escolha para editar arquivos remotos sem atrasos.

As desvantagens são (especialmente se o link também tiver baixa largura de banda e não apenas alta latência) que, para cada arquivo a ser editado, ele precise ser totalmente transferido para o host local e, depois da edição, totalmente transferido para o remoto novamente. O SSHFS fornece alguns tipos de cache (consulte as opções sshfs (1) cache , cache_timeout , cache_x_timeout ) para aliviar um pouco esses problemas. Além disso, se você quiser executar algo no controle remoto, precisará usar outra tela ou prefixar todos os comandos com " ssh remotehost " (por exemplo ssh remotehost sudo service apache restart). Consulte a opção ControlMaster em ssh_config (5) para tornar a execução mais rápida (e sem solicitação de senha).

Você pode emular esse comportamento se estiver apenas executando comandos executando,

ssh user @ targetmachine 'meus comandos em uma string'

mas,

1. isso adiciona um atraso adicional na criação da conexão (pode ser mitigado usando conexões ssh mestre / compartilhadas )
2. se você não tiver uma chave privada sem senha, precisará usar ssh-agentou digitar a senha em
3. claramente não funciona se você estiver interagindo com menus ou editando arquivos etc.

Você pode usar o tmux para obter um eco fluente de sua digitação. Execute o tmux localmente. Se você tiver o shell ssh em um painel e um shell local em um painel abaixo dele, no painel local, poderá enviar chaves para o painel remoto.

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

Comandos interativos e pequenos comandos que digito diretamente no shell ssh atrasado. Assim que o atraso começa a atrapalhar minha digitação, alterno para o painel local e uso as teclas de envio. Isso funciona mesmo no meio da digitação de um comando.

Para atalho, eu adicionei isso ao meu .bashrc

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

Obrigado a Christian Pelczarski por explicar as chaves de envio: https://minimul.com/increased-developer-productivity-with-tmux-part-5.html

Você terá que escapar ao usar aspas, por exemplo

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

Isso faz o que você quer. Porém, você precisa instalar o cliente e o servidor, e o OpenSSH upstream nunca adotou as alterações. https://github.com/hyc/OpenSSH-LINEMODE