Uma sessão SSH que cai depois de alguns minutos pode atrapalhar a administração de um servidor externo, principalmente durante atualizações, manutenção de serviços, edição de arquivos e tarefas demoradas. Em muitos casos, a desconexão está relacionada a timeouts de conexões ociosas, regras de firewall, equipamentos NAT ou instabilidade no caminho entre o computador e o datacenter.

KeepAlive existe em versões anteriores?

Sim. ClientAlive e ServerAlive não são exclusivos do Debian ou Ubuntu mais recentes. O que muda é a disponibilidade de Include, a organização dos arquivos e o gerenciador de serviços. Para clientes em Windows com OpenSSH, as opções também se aplicam, mas o editor e os comandos de permissões do Linux não devem ser copiados literalmente.

No cliente, execute ssh -G usuario@servidor para conferir as opções efetivas. No servidor, regras Match podem depender do usuário e do endereço: use sshd -T -C user=usuario,host=cliente,addr=IP_DO_CLIENTE com valores reais para analisar esse contexto. KeepAlive não implementa reconexão e não substitui tmux.

Documentação: Configuração do cliente · Configuração do servidor.

O OpenSSH oferece mecanismos chamados KeepAlive para detectar se o outro lado continua respondendo. Neste guia, você vai configurar esses mecanismos no servidor Debian ou Ubuntu, ajustar também o cliente SSH quando necessário e aprender a diferenciar um timeout de uma falha real de rede.

O que causa uma queda de conexão SSH?

O SSH mantém uma conexão TCP entre o cliente e o servidor. Quando não há tráfego por determinado período, alguns firewalls, roteadores, equipamentos NAT ou provedores podem remover o registro daquela conexão. O terminal continua aberto, mas a próxima tentativa de comunicação falha.

Também existem outras causas possíveis:

  • Perda de pacotes ou oscilação na conexão de internet.
  • Interrupção ou reinicialização do serviço SSH.
  • Reinicialização, falta de memória ou indisponibilidade do servidor.
  • Timeout configurado no cliente SSH ou em um equipamento intermediário.
  • Limites ou políticas de rede aplicados pelo provedor do servidor.

KeepAlive ajuda principalmente quando a conexão é encerrada por ficar ociosa. Ele não transforma uma rede instável em uma rede confiável e não impede que uma conexão seja perdida durante uma falha física ou uma interrupção completa da rota.

Entenda os três parâmetros do servidor

Os parâmetros a seguir pertencem ao arquivo /etc/ssh/sshd_config, que configura o serviço SSH do servidor. Não confunda esse arquivo com /etc/ssh/ssh_config, usado pelo cliente.

ClientAliveInterval

Define o intervalo, em segundos, após o qual o servidor envia uma mensagem criptografada ao cliente quando não recebeu dados dele. O valor 0 desativa essas mensagens. Com 60, o servidor verifica uma conexão ociosa em intervalos de aproximadamente um minuto.

ClientAliveCountMax

Define quantas mensagens de verificação podem ser enviadas sem que o servidor receba resposta antes de encerrar a sessão. Com intervalo de 60 segundos e limite de 5, uma conexão que não responde pode ser encerrada após aproximadamente cinco verificações, dependendo do momento em que a ausência de resposta começa.

Esse parâmetro não significa que o servidor tentará reconectar o cliente. Ele define quantas verificações sem resposta serão toleradas antes de desconectar uma sessão considerada inativa ou sem comunicação.

TCPKeepAlive

Ativa ou desativa o mecanismo de keepalive do próprio TCP no sistema operacional. Ele é diferente das mensagens ClientAlive, que passam pelo canal SSH criptografado. Em muitas instalações, TCPKeepAlive yes já é o padrão; mantê-lo explícito pode facilitar a leitura da configuração, mas não substitui os outros parâmetros.

Faça um backup antes de alterar o SSH

Como o SSH pode ser o único caminho de administração do servidor externo, não comece editando a configuração sem uma cópia de segurança. Execute no servidor:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Mantenha a sessão atual aberta durante todo o procedimento. Se possível, confirme também que o painel do provedor oferece console de emergência ou acesso serial.

Configure o KeepAlive no Debian ou Ubuntu

Abra o arquivo principal de configuração:

sudo nano /etc/ssh/sshd_config

Procure pelas diretivas ClientAliveInterval, ClientAliveCountMax e TCPKeepAlive. Se estiverem comentadas com #, elas não estão sendo aplicadas naquela linha. Ajuste as diretivas existentes para os valores abaixo, evitando deixar definições duplicadas:

ClientAliveInterval 60
ClientAliveCountMax 5
TCPKeepAlive yes

Se as diretivas não existirem, adicione-as ao arquivo, desde que nenhum arquivo de configuração carregado antes já defina esses parâmetros.

No Nano, salve com Ctrl + O, confirme com Enter e saia com Ctrl + X.

Atenção aos arquivos sshd_config.d

Versões atuais de Debian e Ubuntu podem carregar configurações adicionais de /etc/ssh/sshd_config.d/ por meio da diretiva Include. O OpenSSH normalmente utiliza o primeiro valor encontrado para uma diretiva. Por isso, alterar o arquivo principal pode não produzir o resultado esperado se um arquivo incluído definir o parâmetro antes dele.

Confira os arquivos adicionais:

ls -la /etc/ssh/sshd_config.d/

Para consultar os valores efetivamente interpretados pelo daemon, use:

sudo sshd -T | grep -E '^(clientaliveinterval|clientalivecountmax|tcpkeepalive) '

O resultado deve mostrar os valores efetivos, por exemplo:

clientaliveinterval 60
clientalivecountmax 5
tcpkeepalive yes

Se aparecerem valores diferentes, investigue os arquivos incluídos e a ordem das diretivas antes de continuar.

Valide a configuração antes de aplicá-la

Execute o teste de sintaxe:

sudo sshd -t

Se o comando não exibir mensagens, a configuração passou na validação de sintaxe. Se houver erro, corrija o arquivo indicado antes de recarregar o serviço.

Recarregue o serviço SSH com segurança

Depois da validação, aplique as alterações:

sudo systemctl reload ssh

Em sistemas nos quais a unidade do serviço possui outro nome, confira com systemctl status ssh ou systemctl status sshd. Em Debian e Ubuntu, a unidade normalmente é ssh.service.

Não encerre a sessão atual imediatamente. Abra outro terminal no computador e tente uma nova conexão:

ssh usuario@IP_DO_SERVIDOR

Se a nova conexão funcionar, confira o estado do serviço:

sudo systemctl status ssh --no-pager

Configure também o KeepAlive no computador cliente

O servidor pode enviar mensagens ao cliente, mas o cliente SSH também possui parâmetros próprios. Essa configuração é especialmente útil quando o firewall ou o NAT está encerrando conexões ociosas no caminho entre seu computador e o datacenter.

No computador de onde você inicia a conexão, abra:

nano ~/.ssh/config

Adicione:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 5
    TCPKeepAlive yes

Salve o arquivo. Se ele não existia, proteja-o com permissões adequadas:

chmod 600 ~/.ssh/config

ServerAliveInterval e ServerAliveCountMax são as opções do cliente correspondentes às verificações enviadas pelo lado do servidor. Você também pode aplicar essas opções somente a um servidor específico, substituindo Host * por um apelido ou endereço correspondente à conexão.

Como calcular o tempo aproximado de tolerância

Com ClientAliveInterval 60 e ClientAliveCountMax 5, o servidor envia verificações em intervalos de aproximadamente 60 segundos e tolera até cinco verificações sem resposta. Isso representa uma janela aproximada de cinco minutos antes de encerrar uma sessão que deixou de responder. Não é uma promessa de que a conexão ficará ativa por cinco minutos após qualquer falha: o comportamento depende de quando a falha acontece e de outros timeouts envolvidos.

Diagnostique quedas que continuam acontecendo

Se a conexão continuar caindo, não aumente os valores aleatoriamente. Primeiro descubra se o problema é ocioso, do cliente, do servidor ou da rede.

Consulte os registros do SSH

No Debian e Ubuntu, examine os registros recentes do serviço:

sudo journalctl -u ssh --since "30 minutes ago" --no-pager

Em algumas instalações, mensagens também podem estar em:

sudo tail -n 100 /var/log/auth.log

Procure mensagens de desconexão, encerramento de sessão, falha de autenticação ou reinicialização do serviço.

Verifique se o servidor continua acessível

Em outro terminal do computador cliente, teste a conectividade com o endereço do servidor:

ping IP_DO_SERVIDOR

O ping pode ser bloqueado pelo provedor ou firewall, portanto a ausência de resposta não prova, sozinha, que o servidor está fora do ar. Para analisar perda de pacotes e mudanças de rota, ferramentas como mtr podem ajudar:

mtr -rw IP_DO_SERVIDOR

Instale o MTR no cliente se necessário. Compare os resultados durante períodos estáveis e durante as quedas.

Verifique se o serviço está ativo

Se você ainda tiver acesso ao console do provedor ou a outra sessão administrativa, execute:

sudo systemctl status ssh --no-pager
sudo journalctl -u ssh -n 100 --no-pager

Também vale verificar consumo de memória, CPU e eventos de reinicialização. Uma queda causada por falta de recursos ou reinicialização do servidor não será resolvida por KeepAlive.

Use tmux para não perder tarefas em andamento

KeepAlive ajuda a manter a comunicação, mas não garante que um comando continue vinculado ao terminal depois de uma desconexão. Para tarefas longas, como atualizações, compilações ou manutenção, use um multiplexador de terminal como tmux.

Instale no servidor:

sudo apt update
sudo apt install tmux

Crie uma sessão:

tmux new -s manutencao

Se a conexão cair, conecte-se novamente e retome a sessão:

tmux attach -t manutencao

O tmux não impede a queda da rede. Ele mantém os processos executados dentro da sessão disponíveis para retomada depois que você se reconectar.

Erros comuns ao configurar KeepAlive

  • Editar o arquivo errado: sshd_config configura o servidor; ssh_config configura o cliente.
  • Manter a diretiva comentada: uma linha iniciada por # é tratada como comentário.
  • Duplicar parâmetros: definições anteriores ou arquivos incluídos podem prevalecer. Confira com sshd -T.
  • Recarregar sem validar: sempre execute sshd -t antes de aplicar alterações.
  • Fechar a única sessão antes de testar: mantenha a conexão original aberta até confirmar que uma nova conexão funciona.
  • Esperar que KeepAlive corrija qualquer falha: perda de pacotes, indisponibilidade do provedor e reinicializações exigem diagnóstico próprio.

Pratique: Diferenciar conexão ociosa de processo interrompido.

Use este roteiro para transformar a leitura em uma verificação concreta.

  1. Registre se a queda ocorre após inatividade ou durante transferência. Confira conectividade, logs e opções efetivas antes de modificar os intervalos.
  2. Aplique KeepAlive no lado adequado e teste novamente nas mesmas condições. Se houver regras Match, confirme a configuração para o usuário e endereço do teste.
  3. Execute uma tarefa inofensiva dentro de tmux, desconecte voluntariamente e retome a sessão. Confira que o processo continuou e que é possível acompanhar a saída.

Como conferir o resultado

KeepAlive ajuda a detectar e manter conexões, mas não torna a rede estável. tmux preserva a sessão de terminal no servidor, mas não protege contra reinicialização ou perda de dados. Para manutenção importante, as duas medidas têm funções diferentes e complementares.

Continue o estudo: Segurança no Linux: SSH, firewall, aplicações e backups · Servidor PHP no Linux: Apache, SSH e MySQL ou MariaDB.

Conclusão

Configurar ClientAliveInterval e ClientAliveCountMax no servidor, além de ServerAliveInterval e ServerAliveCountMax no cliente, ajuda a lidar com conexões SSH encerradas por inatividade. O procedimento deve sempre incluir backup, validação com sshd -t, aplicação controlada e teste em uma segunda sessão.

Se as quedas persistirem, investigue os registros do SSH e a rota de rede. Para tarefas longas, mantenha os processos dentro de uma sessão tmux. Assim, mesmo que a conexão caia, você reduz o risco de perder o trabalho em andamento.