Trabalho diariamente no SSH de um desktop Linux para um servidor Amazon EC2 do Amazon AWS e a conexão tem um desempenho muito confiável por dois anos, mas nos últimos dias tenho visto a linha de comando do SSH travar depois que o primeiro caractere do teclado é digitado, somente ao fazer o upload em um furo completo.
Por "travar", quero dizer que tem que ser abortado com ~. em vez de uma longa espera por uma resposta. Provavelmente há uma causa mais detalhada, mas estou vendo apenas o bloqueio após digitar esse primeiro caractere, que foi retornado do servidor após a latência normal (isto é, não está apenas fazendo eco do caractere no cliente SSH) .
Isso só acontece durante períodos de uploads pesados (largura de banda total) da mesma máquina. (Ainda não testei com a largura de banda da rede sendo usada de outra máquina em nossa rede.) Durante essas condições, o problema parece acontecer aleatoriamente e sempre desaparece quando a largura de banda de upload fica mais disponível novamente.
Inserir um retorno de carro nunca causa a suspensão ... por exemplo, inserir várias linhas em branco em uma sucessão curta e tentar inserir "ls" seria interrompido após digitar o L. E é somente após o primeiro caractere que ele bloqueia para cima.
Desktop: Ubuntu 14.04 com OpenSSH_6.6.1p1 (Ubuntu-2ubuntu2.3, OpenSSL 1.0.1f 6 de janeiro de 2014). Servidor: também executando o OpenSSH_6.6.1p1 (versão 1.0.1k-fips).
Configurações de opções atuais, que sempre funcionaram para mim, mesmo durante períodos prolongados de uso intensivo de largura de banda de upload, até muito recentemente:
servidor: / etc / ssh / sshd_config
ClientAliveInterval 15
ClientAliveCountMax 240
TCPKeepAlive no
cliente: ~ / .ssh / config
ServerAliveInterval 15
ServerAliveCountMax 240
TCPKeepAlive no
O próximo passo pode ser aumentar ou diminuir o intervalo de 15 segundos, mas não tenho certeza do que faz mais sentido neste caso. Observe que eu desliguei o TCPKeepAlive porque ter essa opção ativa no cliente no servidor fazia com que as conexões fossem interrompidas a cada 5 minutos. Acredito que isso ocorre porque os pacotes TCP ACK não são permitidos nas sub-redes da AWS ( Como funciona o tcp-keepalive no ssh? )
Independentemente de os leitores estarem na AWS ou não, aguardo com expectativa as configurações ou alterações de opções que o corrigiram. Esse é um problema muito pouco frequente, mas acho que isso significa que minhas configurações de SSH acima devem se tornar mais robustas, e a resposta pode ser muito útil para os usuários da AWS em geral.