PuTTY exibe Conexão esgotada: encontrar a causa

O PuTTY exibe Erro de rede: Tempo de conexão esgotado? Ao abrir a sessão, isso significa que nenhuma resposta útil foi recebida dentro do tempo esperado. O endereço ou a porta podem estar errados, o caminho da rede pode estar inacessível ou assíncrono, ou um equipamento pode estar deixando os pacotes sem resposta. Neste ponto, a senha e a chave SSH ainda não são a causa do problema.

Uma conexão recusada é diferente: a conexão TCP foi rejeitada, por exemplo, por uma porta sem serviço escutando ou por um equipamento intermediário. Essa rejeição não prova por si só que o servidor correto respondeu. Para este outro caso, consulte o diagnóstico de Conexão recusada no PuTTY. O manual descreve oficialmente o timeout do PuTTY como a ausência de resposta do servidor e menciona especificamente um servidor isolado ou desligado e um endereço a ser verificado. Também observa que um timeout pode ocorrer após uma perda de contato durante uma conexão: este guia se concentra na abertura da sessão.

Proceda sem modificar o servidor às cegas: verifique primeiro o destino e o caminho a partir do Windows, e depois compare essas observações com a escuta, a rota de retorno e o filtragem do lado do Linux. Para os comandos do servidor, use um console independente fornecido pelo provedor, a VM ou o acesso físico. Mantenha qualquer sessão SSH já aberta.

Identificar o timeout antes de mudar qualquer coisa

Note o texto exato exibido pelo PuTTY, a hora com o fuso horário, a sessão utilizada, o nome do host, a porta e a etapa em que a falha ocorre. Anote também se você está passando por um proxy configurado no PuTTY, um VPN ou um bastion. Os detalhes disponíveis no Log de Eventos do PuTTY podem ajudar a confirmar o caminho e o endereço tentados.

• Timeout na abertura: nenhuma resposta útil foi recebida dentro do prazo. Isso indica um problema com o endereço, o roteamento ou um filtragem silenciosa, sem diferenciar essas causas.
• Conexão recusada: o caminho recebeu uma rejeição TCP. Verifique o setor dedicado a conexão recusada.
• Servidor recusou nossa chave: o transporte alcançou a etapa de autenticação; é uma outra falha. Você pode então consultar o guia sobre o uso de uma chave SSH com PuTTY.
• Uma sessão estabelecida se desconecta após um período de inatividade: este caso não é o mesmo que um timeout na abertura. Não confie em um ajuste keepalive para corrigir um caminho TCP inicial que não responde.

Não procure um tempo universal a ser ajustado no PuTTY: estender a espera não corrige nem um caminho ausente nem um pacote filtrado.

Verificar o endereço, o DNS e a porta realmente publicada

Abra a sessão salva no PuTTY e verifique o host e a porta nas configurações SSH. O campo host contém um nome ou um endereço, não uma URL com https://. Confirme esses valores com o administrador ou na console do fornecedor antes de substituí-los. Para revisar os campos de uma sessão, siga as configurações de uma sessão SSH no PuTTY.

No PowerShell, substitua server.example.net pelo nome validado e 22 pela porta TCP externa realmente publicada para seu acesso. Esses valores são exemplos, não os parâmetros do seu servidor.

Resolve-DnsName server.example.net -Type A
Resolve-DnsName server.example.net -Type AAAA
Test-NetConnection -ComputerName server.example.net -Port 22 -InformationLevel Detailed

Os dois primeiros comandos exibem separadamente os endereços IPv4 (A) e IPv6 (AAAA) obtidos pela resolução DNS. Compare o endereço retornado com aquele esperado na console do fornecedor. Um registro AAAA pode fazer o PuTTY seguir um caminho IPv6 diferente do caminho IPv4. A documentação da Microsoft sobre Test-NetConnection detalha o resultado TCP e o diagnóstico de rota.

No resultado detalhado de Test-NetConnection, destaque especialmente RemoteAddress, SourceAddress, InterfaceAlias e TcpTestSucceeded. Você pode testar separadamente um endereço já validado para distinguir um problema de resolução de uma falha TCP. Não use um endereço encontrado ao acaso e não aceite uma nova impressão da chave do host sem verificação por um canal confiável.

• TcpTestSucceeded : True significa que este teste estabeleceu TCP para este destino, esta porta e este caminho, naquele momento. Isso não verifica a identidade SSH do servidor. Se o PuTTY falhar novamente, compare o endereço e a porta utilizados, seu proxy, se houver, e as configurações da sessão.
• TcpTestSucceeded : False indica uma falha no teste TCP, mas não distingue sozinho um timeout de uma rejeição nem localiza a perda. Mantenha a mensagem exata do PuTTY e prossiga com as verificações.

Um endereço privado geralmente é acessível apenas a partir da rede pretendida ou de um VPN com a rota correta. Em caso de NAT, a porta utilizada pelo cliente pode diferir da porta interna: por exemplo, uma porta externa conceitual 2222 pode ser redirecionada para a porta interna 22. Faça confirmar a correspondência; não substitua esses exemplos por valores presumidos. Não limpe o cache DNS por reflexo: faça isso apenas se uma entrada local obsoleta tiver sido demonstrada.

Comparar os caminhos Windows, VPN e rede

Verifique a rede ativa, o acesso ao VPN ou ao bastion esperado, as rotas e o endereço de origem utilizado. Se o PuTTY passar por um proxy, um teste direto PowerShell não valida esse proxy: as duas tentativas podem não seguir necessariamente o mesmo caminho.

Os seguintes comandos são leituras do lado do Windows. Para tracert, substitua 192.0.2.20 pelo endereço de um servidor que você está autorizado a testar. 192.0.2.20 é um endereço reservado para exemplos de documentação, não o endereço real do seu servidor.

ipconfig
route print
Test-NetConnection -ComputerName server.example.net -DiagnoseRouting -InformationLevel Detailed
tracert -d 192.0.2.20

ipconfig e route print ajudam a identificar as interfaces e rotas locais. -DiagnoseRouting solicita um diagnóstico da rota; trata-se de um conjunto de parâmetros distinto do teste com -Port, não combine os dois no mesmo comando. tracert exibe etapas do percurso, mas asteriscos podem simplesmente sinalizar que respostas ICMP não estão sendo enviadas. Eles não indicam com certeza o equipamento que bloqueia o SSH. Da mesma forma, um ping bem-sucedido não prova que o SSH é acessível, e um ping falhado não prova que o servidor está desligado.

Se permitido, compare o mesmo host e a mesma porta a partir de outra rede, com os outros parâmetros inalterados. Um sucesso através de um hotspot, por exemplo, sugere uma diferença de caminho, de origem ou de autorização na primeira rede; isso não prova automaticamente que o provedor de acesso bloqueia a porta 22. Uma lista de endereços de origem permitidos pode explicar essa diferença. Verifique as regras de saída do Windows e as políticas de rede com o administrador. Não desative firewalls ou antivírus e não contorne uma política de rede.

Controlar a escuta e a rota de retorno a partir do Linux

Execute essas leituras a partir da console independente do servidor, e não na janela PuTTY onde houve falha. Substitua 192.0.2.10 pelo endereço de origem que o servidor realmente vê, após NAT ou VPN. 192.0.2.10 é um endereço de documentação a ser substituído, não um IP real de cliente. Para um destino IPv6, use ip -6 route get com o endereço IPv6 observado.

ip -br address
ip route
ip route get 192.0.2.10
sudo ss -ltnp
systemctl list-unit-files 'ssh*' --no-pager
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

ip -br address resume os endereços das interfaces; ip route exibe as rotas IPv4 e ip route get indica o caminho escolhido para a origem a ser contatada em retorno. Compare esse caminho com o percurso real: a presença de uma rota padrão não prova que a resposta esteja chegando ao cliente. Em uma distribuição onde o binário não está em /usr/sbin/sshd, adapte seu caminho conhecido em vez de concluir que está ausente.

ss -ltnp mostra os sockets TCP em escuta e, dependendo das permissões, o processo associado. Verifique a porta interna e o endereço de escuta: uma escuta limitada a 127.0.0.1 não é acessível de fora. Uma escuta em [::] não garante por si só a acessibilidade IPv4. O endereço público de um servidor por trás do NAT pode não aparecer necessariamente em suas interfaces Linux.

Identifique a unidade realmente utilizada antes de verificar seu status. Dependendo da distribuição, ela pode ser chamada de ssh.service ou sshd.service; a ativação por socket pode usar ssh.socket. Uma unidade desconhecida não significa necessariamente que SSH esteja ausente. Verifique apenas a unidade identificada, por exemplo:

systemctl status ssh.service --no-pager

Substitua ssh.service pela unidade existente. O manual do OpenSSH para sshd descreve -t como uma verificação de configuração e coerência das chaves, e -T como a exibição da configuração efetiva. Essas opções não reiniciam o serviço. As regras Match podem depender dos parâmetros de conexão; -T por si só não prova a configuração aplicável a cada cliente. Com uma ativação por socket, observe também a escuta real com ss e a unidade de socket.

As diretrizes ListenAddress e Port determinam endereços e portas de escuta na configuração; elas não garantem roteamento, nem uma regra de firewall, nem a publicação da porta pelo NAT. Uma porta sem escuta geralmente produz uma rejeição se o pacote chegar ao host sem filtragem silenciosa: não conclua então que todo timeout significa que o serviço SSH está parado.

Localizar o filtragem sem abrir SSH para toda a Internet

Identifique o firewall efetivamente utilizado antes de interpretar suas regras. Esses comandos são leituras e podem não estar todos disponíveis na sua distribuição:

sudo ufw status verbose
sudo nft list ruleset
sudo firewall-cmd --get-active-zones

Se firewalld estiver ativo, consulte a zona realmente associada à interface, substituindo ZONE pelo nome dela:

sudo firewall-cmd --zone=ZONE --list-all

Um comando ausente não demonstra que não existe filtragem: uma regra pode estar em outro gerenciador, em um roteador ou no provedor. Não acumule gerenciadores de firewall para tentar resolver a falha.

Para a regra correspondente ao trajeto observado, verifique o protocolo TCP, a porta interna, o endereço de origem visto pelo servidor, a ordem das regras e a ação. Uma regra DROP pode deixar a conexão sem resposta; um REJECT pode causar uma rejeição dependendo da forma da rejeição. Examine também os grupos de segurança ou firewalls de nuvem, a rota do fornecedor, o roteador, o redirecionamento de NAT, o VPN e um possível CGNAT. Um teste do endereço público a partir do LAN depende, entre outras coisas, do suporte a NAT loopback; um redirecionamento não funciona necessariamente atrás de um CGNAT.

Corrija apenas uma regra ou uma rota identificada pelas observações, limitando a origem aos endereços necessários. Não abra a porta para 0.0.0.0/0 por padrão e não mova o SSH para a porta 443 como uma solução automática.

Cruzamento de logs e uma captura TCP curta

Consulte os logs ao redor da hora anotada, ajustando a unidade para a realmente usada:

sudo journalctl -u ssh.service --since '10 minutos atrás' --no-pager

Substitua ssh.service pela unidade existente, como sshd.service ou, conforme o caso, ssh.socket. Algumas distribuições também registram eventos em /var/log/auth.log ou /var/log/secure. Um timeout ocorrido antes da troca SSH pode não deixar nenhuma linha de autenticação: um log vazio não demonstra a ausência de tentativa.

Se tcpdump e o GNU timeout estiverem disponíveis e você estiver autorizado a capturar, substitua a porta e o endereço pela porta interna e a origem realmente vistas pelo servidor. Inicie a captura logo antes de uma nova tentativa no PuTTY:

sudo timeout 10 tcpdump -ni any -c 20 'tcp port 22 and host 192.0.2.10'

Nesta comando, a porta 22 e 192.0.2.10 são exemplos documentais a serem substituídos pelos valores observados, não dados do seu problema. A captura para ao final de dez segundos ou após vinte pacotes. Não utilize as opções -A ou -X e não deixe uma captura permanente em execução. Oculte os endereços antes de compartilhar uma saída.

• Nenhum SYN no ponto observado: após verificar a interface, o filtro de captura, a hora e o endereço de origem, examine o destino, a rota ou um filtragem upstream. Isso não prova por si só que um firewall de nuvem bloqueia o tráfego.
• SYN recebido, nenhuma resposta observada: verifique o filtragem local, a escuta e as condições da captura. Não culpe sshd sem mais provas.
• SYN recebido e SYN-ACK emitido, mas nenhum ACK final visível: examine o caminho de retorno ou um filtragem do lado do cliente/intermediário. Uma captura do lado do servidor só não localiza definitivamente a perda.
• SIN seguido de um RST: você está na ramificação da rejeição TCP; consulte o diagnóstico dedicado a Conexão recusada.
• Handshake TCP completo: o TCP funcionou naquele momento. Compare a captura com a tentativa no PuTTY, com o proxy e a etapa SSH alcançada. Isso não prova nem a identidade do servidor nem uma autenticação bem-sucedida.

Corrigindo uma causa provada e validar sem cortar SSH

Antes de qualquer modificação, faça uma cópia do arquivo em questão e certifique-se de ter um console de backup. Realize uma única modificação por vez: corrija o destino da sessão, a rota VPN ou a regra precisa que os testes apontaram. Se você não tiver um console independente, pare as mudanças remotas e envie os resultados ao administrador.

Não modifique chaves, senhas, PermitRootLogin ou algoritmos SSH para corrigir um silêncio de rede antes da autenticação. Se você alterar a configuração SSH, faça primeiro com que sshd -t seja bem-sucedido, em seguida, utilize o recarregamento suportado pela unidade e pela distribuição, depois de verificar seu funcionamento. Um reinício ou um reboot não é um primeiro teste e um recarregamento não corrige necessariamente um socket systemd mal exposto.

Nunca execute ufw disable, nft flush ruleset ou iptables -F. Não pare o Fail2ban às cegas, não abra SSH para todas as fontes e não feche a sessão anterior antes da validação.

Após uma correção, mantenha o console e a sessão antiga abertas. Em uma nova janela PuTTY, teste novamente o mesmo host, a mesma porta e o mesmo caminho. Verifique a impressão SSH por um canal confiável, prossiga até a autenticação e confirme que uma sessão está funcionando. Se a mensagem se tornar Connection refused, retorne para esta ramificação em vez de continuar o diagnóstico do timeout.

Para solicitar ajuda, forneça a hora, o host e a porta, os endereços resolvidos e o endereço de origem, o caminho VPN/proxy, os resultados TCP e a observação do lado do servidor, além da regra suspeita. Exclua endereços e informações sensíveis. Não apresente uma saída de comando não executada como um resultado.