SSH Connection Refused: Guia Completo para Diagnosticar e Resolver o Problema

Pre

O que significa SSH Connection Refused e por que ocorre

Quando tentamos estabelecer uma conexão SSH com um servidor, a mensagem de erro “SSH Connection Refused” pode surgir de forma abrupta. Em termos simples, isso indica que o cliente conseguiu alcançar o host, mas o serviço SSH não aceitou a conexão naquele momento. Em muitos casos, o motivo é o servidor não estar ouvindo na porta esperada, ou haver uma regra de rede que está bloqueando o acesso. Entender a diferença entre “Connection Refused” e “Connection Timed Out” é fundamental para direcionar as próximas ações. Enquanto a recusa aponta para o serviço ou a porta estarem fechados, o timeout costuma indicar latência, DNS incorreto ou filtragem de rede entre o cliente e o servidor.

Principais causas de SSH Connection Refused

Ao enfrentar o erro SSH Connection Refused, é útil entender as causas mais comuns. Abaixo estão os cenários mais frequentes, organizados de forma prática para facilitar o diagnóstico:

Serviço SSH indisponível ou não iniciado

  • O daemon SSH (sshd) não está em execução no servidor.
  • O serviço pode ter falhado durante a inicialização, ou ter sido parado após atualizações ou mudanças de configuração.
  • Em sistemas baseados em Debian/Ubuntu, o nome do serviço costuma ser sshd ou ssh; em algumas distros, pode haver variações.

Porta errada ou ListenAddress mal configurado

  • O sshd pode estar configurado para ouvir em uma porta diferente de 22, por questões de segurança ou políticas internas.
  • ListenAddress pode estar restrito a um IP específico, bloqueando conexões de outras interfaces.

Firewall bloqueando a porta SSH

  • Regras de firewall no servidor (ufw, firewalld, iptables) podem impedir tráfego na porta SSH.
  • Firewalls de rede, como regras de segurança em nuvem (Security Groups, NSG), podem bloquear o tráfego de entrada na porta 22.

Políticas de nuvem ou rede externa

  • Grupos de segurança em ambientes de nuvem podem estar configurados para negar acesso de determinados IPs ou faixas.
  • ACLs de rede, proxies e balanceadores podem interferir na passagem da conexão SSH.

Configuração incorreta do SSHD

  • Parâmetros como Port, PermitRootLogin, PasswordAuthentication, PubkeyAuthentication ou AllowUsers podem restringir o acesso.
  • ListenAddress definido apenas para 127.0.0.1 ou apenas para uma interface interna pode tornar o SSH indisponível externamente.

Problemas com DNS, IPs ou conectividade de rede

  • O cliente pode estar resolvendo um IP incorreto ou desatualizado, levando a uma tentativa de conexão para um host que não está pronto para aceitar conexões SSH.
  • Roteamento, NAT ou QoS podem introduzir latência alta ou erros de entrega que se manifestam como “Connection Refused” em alguns casos.

Como diagnosticar rapidamente o problema de SSH Connection Refused

O diagnóstico eficiente envolve confirmar se o host é alcançável, se o serviço SSH está ativo e se as regras de rede permitem a passagem da porta correspondente. Abaixo seguem etapas práticas para identificar a raiz do problema:

Teste de conectividade básica

  • Verifique se o host responde ao ping (quando permitido pela política de rede):
  • ping -c 4 
  • Teste de resolução de DNS, caso utilize um hostname:
  • nslookup exemplo.com
    dig +short exemplo.com

Verifique se o serviço SSH está ativo no servidor

  • Em sistemas Linux modernos (systemd):
  • sudo systemctl status sshd
    sudo systemctl enable --now sshd
  • Em distribuições que usam o init antigo:
  • sudo service ssh status
    sudo service ssh start

Verifique a porta e a escuta do SSHD

  • Confirme em qual porta o sshd está ouvindo:
  • grep -E '^Port|^ListenAddress' /etc/ssh/sshd_config
    ss -tlpn | grep sshd
    netstat -tlpn | grep sshd

Verifique regras de firewall no servidor

  • Para ufw (Ubuntu/Dedora):
  • sudo ufw status numbered
    sudo ufw allow 22/tcp
    sudo ufw reload
  • Para firewalld (Red Hat/CentOS/Fedora):
  • sudo firewall-cmd --permanent --add-port=22/tcp
    sudo firewall-cmd --reload
  • Para iptables (casos mais antigos):
  • sudo iptables -L -n | grep 22
    sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT
    sudo service iptables save

Verifique políticas de nuvem e rede externa

  • Em AWS, confira Security Groups e Network ACLs para o seu EC2.
  • Em GCP, verifique as regras de firewall da VPC e as etiquetas de rede.
  • Em Azure, examine Network Security Groups (NSG) associadas à sub-rede ou à VM.
  • Certifique-se de que o tráfego de entrada na porta 22 esteja permitido a partir do seu IP.

Examine logs do servidor SSH

  • Registros costumam aparecer em /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL/CentOS):
  • sudo tail -n 200 /var/log/auth.log
    sudo tail -n 200 /var/log/secure
  • Também é útil consultar o journal de sshd:
  • sudo journalctl -u sshd -e
    sudo journalctl -u sshd -b

Resolvendo o SSH Connection Refused: guia passo a passo

Passo 1: reiniciar o serviço SSH

Reiniciar o serviço pode resolver falhas transitórias. Em muitos casos, um simples restart desbloqueia o SSH.

sudo systemctl restart sshd
# Em algumas distribuições
sudo service ssh restart

Passo 2: ajustar Port e ListenAddress

Confirme que o SSHD está ouvindo na porta correta e na(s) interface(s) pretendidas. Edite /etc/ssh/sshd_config se necessário:

sudo nano /etc/ssh/sshd_config
# Verifique ou ajuste:
Port 22
# ListenAddress pode ser 0.0.0.0 para ouvir em todas as interfaces
ListenAddress 0.0.0.0

Após alterações, reinicie o serviço:

sudo systemctl restart sshd

Passo 3: ajustar regras de firewall para a porta SSH

Garanta que a porta SSH está liberada no firewall do servidor e, se aplicável, na nuvem.

sudo ufw allow 22/tcp
sudo ufw reload
# ou
sudo firewall-cmd --permanent --add-port=22/tcp
sudo firewall-cmd --reload

Passo 4: validar a configuração do SSHD

Para confirmar que não há erros de configuração, rode:

sudo sshd -t && echo "sshd_config OK" || echo "Erro em sshd_config"

Se houver mensagens, corrija as diretivas correspondentes e reinicie.

Passo 5: verificar autenticação e chave pública

Problemas de autenticação podem mascarar erros de conectividade. Verifique permissões e formatos:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
# Em servidores que exigem chaves, desative temporariamente a autenticação por senha apenas para testes (seguro apenas em ambiente controlado)
# (Não se recomenda deixar PasswordAuthentication desativado sem ter chaves configuradas)

Passo 6: inspeção de SELinux e AppArmor

Políticas de segurança podem bloquear o SSH mesmo com a configuração correta. Verifique se SELinux está em modo permissivo ou desabilite temporariamente para diagnóstico:

sudo getenforce
# Se retornar Enforcing
sudo setenforce 0

Casos comuns de uso e soluções rápidas

Servidor local Linux com SSHD

Em um servidor Linux doméstico ou empresarial, o problema costuma estar relacionado a um serviço não iniciado ou a uma regra de firewall. Siga os passos de diagnóstico, com especial atenção ao status do sshd, ao ListenAddress e às regras de firewall locais.

SSH para servidores na nuvem com regras de firewall

Ambientes cloud exigem atenção extra às regras de entrada. Mesmo que o servidor esteja funcionando, o SSH Connection Refused pode ocorrer se o grupo de segurança não permitir tráfego na porta 22 ou se houver uma regra de faixa de IPs bloqueando o cliente remoto. Sempre teste com uma janela de acesso temporária para validar alterações.

SSH em containers Docker

Se o SSH estiver rodando dentro de um container, é comum encontrar o erro SSH Connection Refused por não ter a porta publicada no host. Verifique o mapeamento de portas com -p 22:22 no run do container e confirme que o serviço dentro do container está ativo.

Boas práticas para evitar SSH Connection Refused

  • Habilite apenas autenticação por chave pública e desative a autenticação por senha para aumentar a postura de segurança, mantendo a confiabilidade da conexão com SSH.
  • Use portas não padrão apenas quando necessário, mas sempre com regras de firewall atualizadas e regras de acesso restritas.
  • Defina um hardening adequado: AllowUsers ou AllowGroups para restringir quem pode tentar conectar.
  • Implemente fail2ban para mitigar tentativas de acesso indevidas e reduzir o risco de negação de serviço por tentativas repetidas.
  • Monitore logs com ferramentas de observabilidade e configure alertas para falhas de conexão repetidas.

Ferramentas úteis e comandos úteis

  • Verificar portas abertas e processos
  • ss -tlpn
    netstat -tlpn
  • Testar conexão do cliente
  • telnet  22
    nc -zv  22
  • Ver logs de autenticação
  • sudo journalctl -u sshd -e
    sudo tail -n 200 /var/log/auth.log
  • Configurar ajustes de SSHD com segurança
  • sudo nano /etc/ssh/sshd_config
    # alterações recomendadas:
    PermitRootLogin no
    PasswordAuthentication yes|no
    PubkeyAuthentication yes
    

Exemplos práticos de configuração

Abaixo apresentamos dois cenários comuns de configuração para facilitar a compreensão prática. Adaptações podem ser necessárias para o seu ambiente específico.

Exemplo 1: SSH em uma porta não padrão com acesso remoto controlado

# /etc/ssh/sshd_config
Port 2222
ListenAddress 0.0.0.0
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Depois de alterar, reinicie o serviço e abra a porta 2222 no firewall:

sudo systemctl restart sshd
sudo ufw allow 2222/tcp

Exemplo 2: SSH apenas para determinados usuários

# /etc/ssh/sshd_config
AllowUsers usuario1 usuario2

Essa prática restringe o acesso por SSH a usuários específicos, reduzindo a superfície de ataque.

Como evitar erros comuns ao lidar com SSH Connection Refused

  • Faça mudanças de configuração com cuidado e em etapas; sempre mantenha acesso de emergência (console, console de nuvem) para reverter alterações.
  • Nunca desabilite serviços críticos sem entender as implicações de segurança. Por exemplo, desabilitar sshd sem um método alternativo de acesso pode deixá-lo trancado.
  • Documente mudanças de firewall e de rede para facilitar diagnóstico futuro e auditorias de segurança.

Plano de recuperação quando a conexão SSH é perdida

Se, por qualquer motivo, você não consegue restabelecer a conexão SSH, utilize os recursos de recuperação disponíveis no seu provedor de hospedagem:

  • Acesso via console web (console de recuperação) para iniciar, parar ou reiniciar serviços.
  • Consoles de recuperação com ambiente mínimo para inspeção de arquivos e configurações críticas.
  • Restaurar a partir de snapshots ou backups, se houve falha completa do servidor.

Conclusão: por que entender SSH Connection Refused é essencial

O erro SSH Connection Refused é um sinal de que o caminho entre o cliente e o servidor está encontrando barreiras, seja na configuração do servidor, no firewall, ou em políticas de rede da nuvem. Ao seguir uma abordagem sistemática de diagnóstico — verificando o status do sshd, as portas, as regras de firewall, as políticas de nuvem e os logs — é possível identificar rapidamente a origem do problema e aplicar a solução mais adequada. Além disso, adotar boas práticas de segurança, como chave pública para autenticação, default deny e monitoramento de tentativas de acesso, não apenas reduz as chances de o SSH Connection Refused ocorrer, como também eleva a postura de segurança do seu ambiente de TI.

Resumo rápido para resolver SSH Connection Refused

  • Verifique se o serviço sshd está ativo: systemctl status sshd
  • Confirme a porta e o ListenAddress no sshd_config
  • Teste o acesso à porta 22 (ou a porta configurada) com ferramentas de rede
  • Revise regras de firewall no servidor e na nuvem
  • Examine logs para indicar a causa raiz
  • Implemente medidas de segurança e confirme que o acesso remoto funciona conforme o esperado