Como diagnosticar o problema de tempo limite de conexão SSH?

Question

Eu tenho um VPS rodando Debian 7, que eu conecto usando o PuTTY da minha máquina Windows. Na maioria das vezes, PuTTY se conecta bem e eu posso logar bem. No entanto, ocasionalmente, o PuTTY relatará que Connection Timeout .

Quando isso aconteceu da última vez, tentei fazer telnet para a porta que está executando o SSH e ele não pôde se conectar. Eu então tentei telnet para outra porta no VPS que eu sabia que estava executando um serviço e ele se conectou bem.

Quando começar a "reproduzir", se eu tentar ligar 5-10 vezes, posso conectar-me com sucesso. Eu verifiquei o syslog e não pude ver nada interessante lá que pudesse ajudar com esse problema. Se vale a pena qualquer coisa, quando eu me conecto ao servidor quando ele está "tocando", parece ser lento (eu vou digitar um comando e levará um segundo ou dois para aparecer na janela do SSH).

Eu não acredito que isso seja um problema de firewall, já que ele funcionará na maior parte do tempo e, às vezes, não funcionará. Talvez meu host esteja fazendo alguma manutenção?

EDIT: TCPKeepAlive está ativado. Ele foi reproduzido novamente agora e ao tentar fazer telnet para a porta SSH, ele poderia de fato se conectar. Estranho.

    

Answer 1

Para diagnosticar, primeiro você tem que usar um modo verboso de putty.exe.

Abra o cmd e use:

putty.exe -v -ssh user@]host

O -v mostrará muito mais informações.

Para evitar conexões próximas, verifique suas configurações:

No PuTTY (Win): acesse as propriedades da sessão > conexão, e sob Envio de pacotes nulos para manter a sessão ativa, defina Segundos entre keepalives (0 para desligar) para, e. 300 (5 minutos).

No Linux (ssh): Para ativar o keep alive em todo o sistema:

• para todos os usuários: edite o / etc / ssh / ssh_config.
• apenas para você: edite ~ / .ssh / config.

Insira o seguinte:

Host *
    ServerAliveInterval 300
    ServerAliveCountMax 2

Você também pode fazer com que seu servidor OpenSSH mantenha todas as conexões com clientes adicionando o seguinte em / etc / ssh / sshd_config:

KeepAlive yes
ClientAliveInterval 300
ClientAliveCountMax 2

Essas configurações farão com que o cliente SSH ou servidor envie um pacote nulo para o outro lado a cada 300 segundos (5 minutos), e desista caso ele não receba nenhuma resposta após 2 tentativas, ponto no qual a conexão é provável ter sido descartado de qualquer maneira.

Na página do manual ssh_config:

ServerAliveCountMax Sets the number of server alive messages (see below) which may be sent without ssh(1) receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session. It is important to note that the use of server alive messages is very different from TCPKeepAlive (below). The server alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. The server alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive.

The default value is 3. If, for example, ServerAliveInterval (see below) is set to 15 and ServerAliveCountMax is left at the default, if the server becomes unresponsive, ssh will disconnect after approximately 45 seconds. This option applies to protocol version 2 only; in protocol version 1 there is no mechanism to request a response from the server to the server alive messages, so disconnection is the responsibility of the TCP stack.

ServerAliveInterval Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server, or 300 if the BatchMode option is set. This option applies to protocol version 2 only. ProtocolKeepAlives and SetupTimeOut are Debian-specific compatibility aliases for this option.

    

Answer 2

Parece que você tentou descartar um problema de rede mais amplo e provavelmente o fez corretamente.

(Eu sempre pensaria em medir a medição de latência de rede, olhando para ping e traceroute . Porque não precisa demorar muito para apenas ping e ver se há um problema muito amplo, que poderia estar com sua conexão de internet local.)

Acho que há dois problemas comuns a serem observados quando você estiver usando um VPS.

1. Se você tentar correr muito em um VPS muito pequeno. Você pode usar muita memória e, em seguida, estar constantemente trocando dados / códigos para dentro e fora do disco. Agora o seu disco está muito ocupado e tudo está lento, por ex. demora muito tempo, por ex. para carregar o SSH.

   Diagnóstico: monitore seu uso de memória.

   em cima pode ser uma maneira conveniente de criar um log de uso de memória muito grosseiro e algumas outras informações de desempenho. atop custa cerca de 5 / 10M de RAM para execução (32 bits versus 64 bits). Isso funcionará para um VPS baseado em Xen ou KVM; Não tenho certeza de como isso funcionaria com o OpenVZ (ou outro VPS baseado em contêiner).

2. O problema do "vizinho barulhento". Às vezes causado por outra pessoa que está executando o problema anterior :). Em um sistema virtual, você está compartilhando hardware com muitos outros. Se algumas pessoas estiverem usando mais IOs em disco (ou possivelmente mais memória) do que "esperado", os outros VPS no mesmo hardware sofrerão.

   O monitoramento também pode ser útil para diagnosticar isso. No entanto, talvez seja um pouco mais difícil e especializado um problema.

Pode ser melhor concentrar-se em poder medir e monitorar (log / graph) algo que se aproxime do tempo de resposta real do seu (s) serviço (s). Quando o seu VPS é basicamente um servidor da Web público, esse é um desejo comum e há serviços gratuitos / limitados que oferecem isso para você.

Podemos concluir que um bom hospedeiro forneceria conselhos básicos e / ou ferramentas para ambos os tipos de monitoramento, mas não sei quão comum é realmente:).

Esses tipos de problemas serão conhecidos pelo seu provedor de VPS. Uma técnica de diagnóstico é contatá-los e descrever o problema que você está enfrentando: -).

    

Answer 3

Eu não sei exatamente por que isso acontece (como podemos ver, o consenso geral parece ser que existem muitos fatores sobre os componentes de origem, destino e rede que podem afetar isso).

No entanto, descobri que usar o scp para copiar um pequeno arquivo fictício antes de fazer o ssh real parece quase eliminar esse problema em vários ambientes Linux e AIX:

    echo Copying small dummy file to $DESTINATION_IP
    scp -o StrictHostKeyChecking=no -o PasswordAuthentication=no dummy.tmp testuser@$DESTINATION_IP:/tmp/. 
    echo Testing ssh again
    ssh -n -tt -o StrictHostKeyChecking=no -o PasswordAuthentication=no testuser@DESTINATION_IP

Apenas meu 2c