SSH: Connection Refused ou Timed Out? Como Diagnosticar

O que "Connection refused" e "Connection timed out" significam no SSH

Uma ligação SSH recusada e uma ligação SSH que excede o tempo limite são falhas opostas. A correção de uma nunca resolve a outra. Recusada significa que o pacote chegou ao servidor e o kernel do servidor respondeu que não há nada a escutar nessa porta. O tempo limite significa que o pacote não chegou a nenhum sistema que pudesse responder. Por isso, o cliente esperou e desistiu. Uma recusa é um problema do serviço no servidor. Um tempo limite é um problema no caminho até ao servidor.

Leia a linha exata apresentada pelo cliente. A formulação contém todo o diagnóstico.

ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out

O tempo de resposta é a segunda pista. Uma recusa regressa imediatamente, aproximadamente no tempo de uma ida e volta. Um tempo limite demora muitos segundos a ser apresentado, porque o cliente continua a retransmitir o pacote até desistir. O macOS apresenta Operation timed out para a mesma condição. Se o protocolo ainda não lhe for familiar, como funciona o SSH e o que o sshd faz apresenta o contexto assumido por este guia.

Por que "Connection refused" é uma boa notícia

"Connection refused" é um reset TCP (protocolo de controlo de transmissão). O seu cliente envia um pacote SYN para a porta 22. O pacote atravessa a Internet, chega à pilha de rede do servidor e o kernel não encontra nenhum socket a escutar nessa porta. Por isso, responde com um pacote RST (reset). O cliente SSH converte esse RST no texto Connection refused.

Esse único pacote de resposta confirma muitas coisas. O endereço está correto. O host está ligado e existe encaminhamento de rede. Nenhum elemento no caminho está a descartar silenciosamente o tráfego para essa porta, porque algo respondeu a partir da outra extremidade. Portanto, todas as hipóteses restantes estão no próprio servidor.

• sshd não está em execução porque falhou ao iniciar ou nunca foi ativado.
• sshd está a escutar noutra porta, normalmente depois de uma alteração de hardening.
• sshd está associado a um único endereço, como ListenAddress 127.0.0.1, pelo que apenas o próprio servidor consegue alcançá-lo.
• Uma firewall está configurada para rejeitar em vez de descartar, por isso envia o RST em nome do host. A ação reject do ufw e uma regra nftables terminada em reject with tcp reset fazem isto.

Há outro caso que parece igual, mas não é: introduziu um endereço que pertence a outro host ativo. Esse host responde ao seu SYN, não tem SSH na porta 22 e recusa a ligação de forma normal. Confirme o endereço antes de passar uma hora a trabalhar no servidor errado. Saber o que é realmente uma porta em escuta no Linux torna o resto desta secção mais rápido de ler.

Como corrigir "Connection refused"

Não é possível corrigir isto por SSH, porque o próprio SSH está com problemas. Abra a consola web ou a consola série do seu fornecedor, autentique-se nela e execute os comandos seguintes.

systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

systemctl status ssh usa o nome da unidade no Ubuntu e no Debian. No RHEL e nos seus derivados, como o AlmaLinux, a unidade é sshd. ss -tlnp lista todos os sockets TCP no estado de escuta, juntamente com o processo que os possui, e é a fonte de verdade: se nenhuma linha mencionar sshd, não há nada a escutar, independentemente do que o ficheiro de configuração indicar. sshd -T mostra a configuração efetiva depois de todos os ficheiros Include serem combinados. É aí que aparece uma porta esquecida em /etc/ssh/sshd_config.d/.

Leia atentamente a coluna de endereços. 0.0.0.0:22 significa todos os endereços IPv4 do servidor. [::]:22 significa todos os endereços IPv6. 127.0.0.1:22 significa apenas loopback. Por isso, qualquer ligação remota a esse endereço é recusada, enquanto uma ligação local ssh localhost funciona normalmente.

Se não houver nada a escutar, inicie o serviço e leia o erro quando este não arrancar.

sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pager

sshd -t analisa a configuração e mostra o ficheiro e o número da linha de uma diretiva inválida, sem alterar o serviço em execução. Execute-o antes de cada reinício, porque uma configuração rejeitada faz com que o sshd termine ao arrancar e a ligação seguinte seja recusada.

A armadilha da ativação por socket no Ubuntu

O Ubuntu 24.04 disponibiliza uma unidade de socket do systemd para o OpenSSH. Quando essa unidade está ativada, o systemd mantém a porta em escuta e inicia o sshd por ligação. Nesse caso, Port 2222 em sshd_config não altera nada e o servidor continua a responder na porta antiga. Verifique o modo em utilização antes de editar qualquer ficheiro.

systemctl is-enabled ssh.socket
systemctl status ssh.socket

Se o socket estiver ativado, defina a porta na unidade de socket, e não em sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

A linha ListenStream= vazia é necessária porque as definições de lista do systemd são adicionadas à configuração existente. Se a omitir, o servidor escuta nas duas portas. Aplique a alteração com sudo systemctl daemon-reload e sudo systemctl restart ssh.socket. Em seguida, confirme com sudo ss -tlnp que a nova porta é a porta mantida pelo socket. Alterar a porta é uma etapa normal de proteção do SSH num VPS e é a etapa que mais frequentemente impede o acesso ao servidor.

Por que "Connection timed out" significa que nada respondeu

Um timeout significa silêncio. O cliente enviou um SYN, retransmitiu-o várias vezes durante um ou dois minutos e nunca recebeu nenhum pacote de resposta. Isto não prova nada sobre o servidor, porque nunca foi recebida qualquer resposta do servidor.

O silêncio é exatamente o que uma regra DROP produz, e o descarte é deliberado. Uma rejeição informa a quem estiver a fazer uma varredura que o host existe. Por isso, o ufw e o firewall de rede de cada fornecedor de cloud descartam os pacotes indesejados e não enviam nada de volta. O seu timeout normalmente é causado por um firewall que está a cumprir a sua função numa porta que pretendia ter aberta.

• O endereço está errado: um registo DNS ainda aponta para um servidor que foi recriado, ou existe um erro de digitação que aponta para um endereço que ninguém utiliza.
• O host não está ativo: está desligado ou a meio de um reboot. Uma suspensão do fornecedor por falta de pagamento tem o mesmo aspeto a partir do exterior.
• O firewall do host descarta a porta 22, na maioria dos casos porque ufw enable foi executado antes de existir qualquer regra de permissão.
• Um firewall do fornecedor, à frente da instância, descarta o pacote, e o sistema operativo nunca o recebe.
• A sua própria rede bloqueia a porta 22 de saída, algo comum em ligações de escritórios e hotéis.

Execute o teste do lado correto da ligação

Este é o erro que mais tempo desperdiça. Não é possível diagnosticar um pacote descartado a partir do servidor que não o está a receber. Se conseguisse iniciar sessão para executar o comando, não teria esse problema. Todos os comandos desta secção são executados na sua própria máquina.

getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22

getent hosts mostra o endereço que a sua máquina vai realmente utilizar. Isto deteta um registo DNS desatualizado em segundos. ssh -G apresenta as definições que o seu cliente aplica depois de ler ~/.ssh/config. Assim, deteta um bloco Host antigo que altera silenciosamente o nome do anfitrião, a porta ou o utilizador. ssh -vvv mostra até onde a tentativa chegou. Uma última linha sobre a ligação ao endereço, seguida de uma pausa longa, indica um timeout. Uma linha que apresenta a versão remota do OpenSSH significa que o TCP já funcionou e que o problema real está na autenticação. No Windows, Test-NetConnection 203.0.113.10 -Port 22 no PowerShell substitui nc.

Teste a porta, não o anfitrião. Uma falha de ping não prova nada, porque muitos fornecedores filtram ICMP (Internet Control Message Protocol) na periferia da rede. Um ping bem-sucedido também não prova nada, porque não fornece informação sobre a porta 22.

Depois, altere a única variável que nenhum comando pode alterar por si: a sua rede. Tente novamente através do hotspot do telemóvel. Se a ligação funcionar pelo hotspot, mas não a partir do seu posto de trabalho, o bloqueio está do seu lado da Internet ou o endereço do escritório foi banido no servidor.

O firewall do provedor que você não consegue ver no servidor

A maioria dos painéis de VPS oferece um firewall de rede, às vezes chamado de grupo de segurança ou firewall de nuvem, que é executado antes da sua instância e mantém a própria lista de regras. ufw status no servidor não consegue vê-lo. Por isso, “mas eu já permiti a porta 22” é uma frase tão comum. Abra o painel e consulte essa lista antes de reescrever uma única regra no servidor.

Um comando resolve a questão, mas requer acesso ao console. Inicie-o no servidor e tente conectar-se a partir do seu laptop enquanto ele estiver em execução.

sudo tcpdump -ni any tcp port 22

Se nada aparecer enquanto o cliente tentar conectar-se, os pacotes estão sendo descartados antes de chegar ao sistema operacional. Nesse caso, o problema está no firewall do provedor ou na rota até o host. Se os pacotes SYN chegarem e nenhuma resposta sair, o descarte é local e pertence ao ufw ou ao nftables. Esse teste divide ao meio a investigação de um timeout. Por isso, vale a pena aceder ao console.

ordenação do ufw, IPv6 e um bloqueio que você mesmo criou

O erro de ordenação do ufw bloqueia mais pessoas do que qualquer outra coisa neste procedimento. sudo ufw enable aplica imediatamente uma política padrão de negar conexões recebidas. Sem uma regra para SSH, a sessão atual continua ativa devido ao estado de conexões estabelecidas, enquanto todas as novas conexões expiram. Permita primeiro. Depois, ative o ufw.

sudo ufw allow OpenSSH
sudo ufw status verbose

O perfil de aplicação OpenSSH cobre apenas a porta 22. Se você pretende mover o SSH para a porta 2222, a regra necessária é sudo ufw allow 2222/tcp. Adicione-a antes de alterar a porta, não depois. O conjunto de regras mais amplo é explicado em fundamentos do firewall ufw para um VPS, e a ordenação segura faz parte de o que fazer nos primeiros dez minutos em um VPS novo.

O IPv6 produz um timeout que parece inexplicável. Se o hostname tiver um registro AAAA, o cliente tentará primeiro usar IPv6. Assim, um servidor com regras IPv6 ausentes fica aguardando, enquanto uma tentativa direta por IPv4 funciona. Separe os dois protocolos manualmente.

ssh -4 user@vps.example.com
ssh -6 user@vps.example.com

Se -4 conectar e -6 não conectar, o problema está nas regras IPv6 do servidor. Como abrir a mesma porta para IPv6 no ufw explica o procedimento.

Você também pode ter bloqueado o próprio endereço. O fail2ban monitora o log de autenticação e insere uma regra de firewall contra endereços que falham repetidamente. Uma chave incorreta ou um script que continua tentando em segundo plano pode bloquear o endereço de um escritório inteiro. Um bloqueio que descarta os pacotes se parece com um timeout. Um bloqueio que rejeita a conexão retorna No route to host. No console:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24

Adicionar o próprio endereço a ignoreip faz parte de uma configuração funcional do fail2ban no Ubuntu 24.04.

Erros que não são recusas nem expiraram

No route to host significa que foi recebida uma mensagem ICMP de destino inacessível. O seu próprio computador não tem uma rota para essa rede ou algum dispositivo no caminho respondeu com uma rejeição administrativa. É isso que uma regra iptables REJECT envia.

Network is unreachable indica que é o seu próprio computador a responder. Não existe qualquer rota para essa família de endereços. Esta é a resposta habitual quando um nome resolve apenas para um endereço IPv6 numa ligação apenas IPv4.

kex_exchange_identification: Connection closed by remote host significa que a ligação TCP foi estabelecida, mas o servidor terminou a ligação antes de concluir a troca de chaves. A porta está aberta e o sshd está ativo. Verifique a carga do servidor, MaxStartups ou uma interdição aplicada enquanto estabelecia a ligação.

Permission denied (publickey) significa que chegou à autenticação, mas falhou nessa etapa. A rede e a firewall estão a funcionar corretamente, pelo que nada neste guia se aplica. Consulte como corrigir Permission denied (publickey) no SSH.

Como recuperar o acesso e evitar um segundo bloqueio

Todo VPS sério disponibiliza uma consola que não depende da rede do sistema convidado: uma consola série ou um ecrã VNC no navegador. Essa consola é a rota de recuperação para os dois ramos deste guia, porque continua a funcionar quando o sshd está parado e quando uma regra de firewall descarta tudo. Localize-a no painel, autentique-se como root ou como o seu utilizador normal e execute as verificações anteriores. Se nunca definiu uma palavra-passe para root, a maioria dos painéis permite repor uma.

Quando não existe consola, a alternativa é o modo de recuperação do fornecedor. Este arranca um sistema de recuperação pequeno e monta o seu disco, para que possa editar /etc/ssh/sshd_config ou eliminar uma regra de firewall offline e reiniciar.

Dois hábitos evitam o próximo bloqueio. Mantenha uma segunda sessão SSH aberta sempre que editar o sshd ou a firewall, porque essa sessão permanece ativa com o estado já estabelecido enquanto testa uma sessão nova. Além disso, configure uma reversão automática antes de fazer uma alteração de firewall arriscada.

sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer

A primeira linha agenda a desativação automática do ufw dentro de dez minutos. Aplique as novas regras, abra uma sessão SSH nova para confirmar que funcionam e execute depois a segunda linha para cancelar a reversão. Se ficar bloqueado, aguarde dez minutos e a firewall será desativada automaticamente. O servidor ficará sem filtragem até ativar novamente o ufw. Utilize este procedimento enquanto está junto do teclado, e não como configuração permanente.

A ordem de trabalho

1. Leia o texto do erro e observe quanto tempo demorou a aparecer.
2. Recusado: aceda à consola e verifique sudo ss -tlnp para confirmar se existe um socket à escuta, a porta utilizada e o endereço ao qual está associado.
3. Tempo limite esgotado: a partir da sua própria máquina, confirme o endereço. Depois, verifique a firewall do fornecedor no painel e, em seguida, a firewall do host no servidor.
4. Nenhuma dessas strings: já existe uma ligação TCP. Trate o problema como uma questão de autenticação ou de carga do servidor, não como um problema de rede.

FAQ

Por que o SSH informa "Connection refused" quando o sshd está em execução?

Porque a recusa vem do socket, não do serviço, e um sshd em execução ainda pode recusar a ligação. Abra a consola do fornecedor e execute sudo ss -tlnp. Um socket em 127.0.0.1:22 recusa todos os clientes remotos, porque está associado apenas ao loopback. Um socket noutra porta recusa todos os clientes que continuam a utilizar a porta 22. Se for utilizada a ativação de sockets do systemd, a porta vem de ssh.socket e não de sshd_config. Por isso, verifique também systemctl is-enabled ssh.socket. Uma regra reject do ufw também devolve uma recusa em nome do host. Por isso, leia sudo ufw status verbose antes de tirar conclusões.

Por que o SSH entra em timeout quando o ufw já permite a porta 22?

Porque um timeout significa que não houve resposta, e o ufw não é a única firewall no caminho. A maioria dos painéis de VPS executa uma firewall de rede à frente da instância, e o sistema operativo nunca vê o que essa firewall descarta. Na consola, execute sudo tcpdump -ni any tcp port 22 e tente ligar-se a partir do seu portátil enquanto o comando estiver em execução. Se não chegarem pacotes, o descarte ocorre a montante, no painel. Se chegarem pacotes sem que saia uma resposta, o descarte é local, no ufw ou no nftables.

Um ping falhado significa que o meu VPS está indisponível?

Não. Muitos fornecedores filtram ICMP na periferia da rede. Por isso, um servidor que esteja a servir tráfego normalmente pode ignorar todos os pings enviados. Um ping bem-sucedido também é uma indicação fraca no sentido oposto, porque não informa se a porta 22 está aberta. Teste a própria porta com nc -vz -w 5 203.0.113.10 22 a partir da sua máquina, ou com Test-NetConnection 203.0.113.10 -Port 22 no PowerShell do Windows.

Alterei a porta SSH e agora nada se liga. O que aconteceu?

Há duas causas relacionadas com a ordem das operações. Se a firewall nunca recebeu uma regra para a nova porta, as tentativas para a nova porta entram em timeout, enquanto a porta 22 recusa a ligação. Por isso, sudo ufw allow 2222/tcp deve ser executado antes da alteração da porta, e não depois. Se o sistema utilizar a ativação de sockets do systemd para o SSH, Port 2222 em sshd_config será ignorado, e o systemd continuará a manter a porta antiga. Pode confirmar isso com systemctl is-enabled ssh.socket. Recupere o acesso através da consola do fornecedor, corrija a causa aplicável e, depois, ligue-se com ssh -p 2222 user@203.0.113.10 quando sudo ss -tlnp mostrar o novo socket.