SSH connection refused vs timed out: diagnostique em dois minutos

Connection refused e Connection timed out parecem irmãos — de qualquer forma o SSH não conectou —, mas são achados opostos e apontam para metades diferentes da pilha. Saber qual dos dois você está vendo corta a lista de suspeitos pela metade antes de você digitar um único comando de diagnóstico. Esta é a rotina de dois minutos: o que cada erro prova, a única sondagem que os separa de todo o resto, e uma lista de verificação para cada ramo. (Para os erros que acontecem depois que a conexão TCP dá certo — falhas de autenticação, avisos de chave de host, sessões que morrem — veja o decodificador.)

Erro	O que prova	Causa provável	Primeiro comando
Connection refused	O host está no ar e disse não ativamente (voltou um RST)	Nada escutando naquela porta, ou uma regra de firewall REJECT	ss -tlnp | grep sshd a partir do console
Connection timed out	Nada voltou — silêncio no caminho	IP errado, host fora do ar, ou um DROP silencioso (security group/firewall da nuvem)	nc -vz host 22, depois verifique o firewall da nuvem

O que cada erro realmente prova

Connection refused significa que a máquina respondeu a você. Seu SYN TCP chegou a um host vivo, e o host disse não ativamente — voltou um pacote RST ou um ICMP port-unreachable. São surpreendentemente boas notícias: o IP está certo, a rota funciona, o host está no ar, e nada no caminho está comendo seus pacotes. O problema é estreito: nada está escutando naquela porta, ou uma regra de firewall está rejeitando (não descartando) a porta.

Connection timed out significa silêncio. Seus pacotes saíram e nada nunca voltou. Isso quase nada prova sobre o servidor — ele pode estar fora do ar, o IP pode estar errado, ou (na maioria das vezes) algo entre você e ele está silenciosamente descartando pacotes: um security group da nuvem, um firewall com política DROP, um buraco negro de NAT ou VPN.

Um mnemônico: refused = a máquina falou com você; timed out = ela nunca falou. Refused é um problema de host. Timed out costuma ser um problema de caminho.

Passo 1: sonde a porta, não o host

Pule o ping como primeiro movimento — ele testa a coisa errada nas duas direções. Um host que responde ao ping ainda pode descartar a porta 22 (firewalls de nuvem filtram por porta), e um host que ignora o ping pode estar servindo SSH alegremente (o ICMP é bloqueado em todo lugar). O ping não prova nada do que você precisa.

Sonde a porta de verdade:

nc -vz example.com 22

(Sem netcat? telnet example.com 22 funciona — qualquer saída começando com SSH-2.0-... significa que o sshd respondeu.) Três resultados:

• Connection refused — siga o ramo do refused abaixo.
• Trava e depois expira — siga o ramo do timed-out.
• Tem sucesso — o TCP está bem e o seu problema é dentro do próprio SSH: usuário ou chave errados (Permission denied (publickey) tem o seu próprio guia (em inglês)), uma incompatibilidade de chave de host, ou algo que o ssh -v vai nomear sem rodeios.

O ramo do refused: encontre o que (não) está escutando

Você vai precisar de outro jeito de entrar na máquina — o console web do provedor existe para exatamente este momento.

O sshd está rodando?

systemctl status sshd     # the unit is "ssh" on Debian/Ubuntu

Se ele estiver morto, não apenas reinicie — verifique por quê: journalctl -u sshd (ou -u ssh) mostra como ele saiu. Uma causa frequente é uma edição de config que não é interpretada; sshd -t valida o arquivo e nomeia a linha ruim antes de você reiniciar na mesma falha.

Ele está escutando onde você acha?

sudo ss -tlnp | grep sshd

Duas pegadinhas se escondem nessa saída. A porta: alguém moveu o SSH para a 2222 e você está batendo na 22 — conecte com ssh -p 2222, depois fixe isso por host em ~/.ssh/config (em inglês) para nunca mais redescobrir. O endereço: uma linha ListenAddress pode prender o sshd a uma única interface, então ele responde no IP privado e recusa no público.

O firewall local está rejeitando? sudo ufw status, sudo iptables -L -n ou nft list ruleset — procure regras REJECT que cubram a sua porta. Uma regra REJECT produz exatamente este erro: o host está no ar, o sshd pode até estar escutando, e o firewall responde no lugar dele.

Você foi banido? A ação padrão do fail2ban rejeita, então um banimento parece Connection refused — só do seu IP. O sinal: funciona de um hotspot do celular, mas não da sua rede. Do console: fail2ban-client status sshd, depois fail2ban-client unban <your-ip> — e corrija o que quer que tenha repetido uma credencial errada vezes suficientes para merecer o banimento.

O ramo do timed-out: encontre onde os pacotes morrem

Confirme o endereço primeiro. É constrangedor exatamente uma vez. ssh -v imprime o IP que ele de fato disca — confira contra o painel do provedor. DNS obsoleto depois de uma migração, e o IP elástico que não sobreviveu a uma parada de instância, são ambos clássicos.

Verifique o firewall da nuvem em seguida, porque é a resposta na maioria das vezes. Security groups (AWS), NSGs (Azure) e regras de firewall de VPC (GCP) descartam o tráfego de entrada por padrão — silenciosamente, o que é exatamente um timeout. Procure uma regra de entrada permitindo TCP 22 do seu endereço. A variante traiçoeira: uma regra travada em “My IP” meses atrás, e o seu IP mudou desde então. ACLs de rede no nível da sub-rede são uma segunda camada, menos visitada, que vale uma olhada quando o security group parece certo.

Trace o caminho quando as regras de nuvem estiverem corretas:

traceroute example.com                  # mtr example.com for a live view
sudo traceroute -T -p 22 example.com    # TCP to the actual port — closest to the truth

O traceroute simples usa UDP ou ICMP, que os firewalls tratam de forma diferente do TCP 22 — a forma -T -p 22 testa o que o SSH de fato vivencia. Onde os saltos param de responder é, mais ou menos, onde os seus pacotes morrem.

Suspeite do seu próprio lado. Redes de visitantes de hotéis, cafés e escritórios rotineiramente bloqueiam a saída pela 22, e VPNs corporativas a redirecionam ou descartam. O teste de isolamento é o hotspot do celular: se o SSH funciona ali, o seu servidor está bem e a rede em que você estava é o problema.

Um firewall com política DROP na própria máquina parece idêntico, de fora, a um descarte do lado da nuvem — se você tem acesso ao console, verifique o iptables/nftables na máquina também.

O exótico: port knocking. Um servidor rodando knockd descarta tudo até ver uma sequência secreta de tentativas de conexão em outras portas. Se um antecessor configurou a máquina e toda porta expira de todo lugar, pergunte por aí antes de queimar uma tarde com teorias de roteamento.

Guarde a versão de dois minutos

A rotina inteira comprime bem: sonde a porta com nc -vz. Refused → entre pelo console, verifique o sshd, a porta de escuta, as regras REJECT, o fail2ban. Timed out → confirme o IP, verifique o security group da nuvem, depois o traceroute e a sua própria rede. O ping não aparece em lugar nenhum dela.

Os fatos recorrentes — qual porta, qual usuário, qual host precisa de keepalives — pertencem ao ~/.ssh/config (em inglês), não à sua memória. E parte do diagnóstico pode ser estado permanente, em vez de uma correria no meio do incidente: o Termalin guarda a porta, o usuário, a chave e as configurações de keepalive junto de cada host salvo e mostra o status ao vivo por host — então “a máquina está sequer no ar?” e “qual era mesmo a porta?” são respondidas antes de você conectar, e o servidor que só escuta na 2222 deixa de ser algo que você redescobre a cada trimestre.

---

O Termalin é um cliente SSH gratuito e multiplataforma que mantém portas, usuários, chaves e keepalives por host junto do host e mostra o status ao vivo de cada host — baixe o Termalin, ou veja a lista completa de recursos.