Centro de Conhecimento DevOps
Centro de Conhecimento DevOps

Como Corrigir Rapidamente Erros de Conexão Recusada SSH

Encontrar um erro "Conexão Recusada" de SSH pode interromper o gerenciamento do seu servidor remoto. Este guia abrangente detalha a solução de problemas passo a passo, focando em diagnósticos críticos do lado do servidor. Aprenda a verificar o status do seu daemon SSH, verificar e configurar regras de firewall (UFW, firewalld), inspecionar as configurações de `sshd_config` e utilizar testes básicos de conectividade de rede. Comandos práticos e conselhos acionáveis são fornecidos para resolver rapidamente o problema e restaurar o acesso seguro aos seus sistemas, garantindo que você retome o controle rapidamente.

49 visualizações

Solucionando Erros de Conexão SSH Recusada Rapidamente

O SSH (Secure Shell) é a espinha dorsal do gerenciamento remoto de servidores, permitindo comunicação segura e criptografada entre sua máquina local e um servidor remoto. No entanto, encontrar um erro ssh: connect to host <IP_ADDRESS> port 22: Connection refused pode ser um obstáculo frustrante, impedindo você de acessar seus sistemas cruciais.

Este artigo fornece um guia abrangente, passo a passo, para diagnosticar e resolver o erro comum de 'Conexão Recusada'. Exploraremos os principais culpados, desde daemons SSH inativos até firewalls mal configurados e configurações incorretas do servidor, equipando você com o conhecimento e os comandos para recuperar rapidamente o acesso aos seus servidores.

Entendendo o Erro 'Connection Refused' (Conexão Recusada)

Quando você recebe um erro Connection refused, isso significa que seu cliente SSH alcançou o servidor remoto com sucesso, mas o servidor negou explicitamente a conexão na porta especificada. Isso é diferente de um erro Connection timed out (onde o cliente não conseguiu alcançar o servidor) ou um erro No route to host (onde o caminho de rede está quebrado).

O status "refused" (recusado) aponta diretamente para um problema no lado do servidor que está ativamente impedindo o serviço SSH de aceitar conexões. Isso geralmente envolve o daemon SSH não estar em execução, um firewall bloqueando a conexão ou uma configuração incorreta dentro do próprio serviço SSH.

Causas Comuns de 'Connection Refused'

Vários fatores podem levar a uma conexão SSH ser recusada. Entender esses fatores ajuda a restringir o processo de solução de problemas:

  • Daemon SSH (sshd) Não em Execução: A causa mais comum. O processo do servidor SSH pode ter travado, sido parado ou falhado ao iniciar na inicialização.
  • Firewall Bloqueando a Porta 22 (ou porta personalizada): O firewall do servidor (ex: UFW, firewalld, iptables) está impedindo conexões de entrada na porta SSH.
  • Configuração Incorreta do Daemon SSH: O arquivo sshd_config pode estar mal configurado, fazendo com que o daemon SSH escute em uma porta diferente, em uma interface de rede errada ou recuse conexões para usuários/métodos específicos.
  • Problemas de Conectividade de Rede (Menos Comum para 'Refused'): Embora menos provável para um erro "refused", um problema fundamental de rede pode, às vezes, se manifestar inesperadamente.
  • Restrições do SELinux ou AppArmor: Melhorias de segurança como SELinux ou AppArmor podem estar impedindo o sshd de operar corretamente, especialmente após configurações personalizadas ou alterações no sistema.

Guia Prático de Solução de Problemas

Vamos mergulhar nas etapas práticas para diagnosticar e corrigir o erro 'Connection Refused'.

Passo 1: Verificar o Status do Daemon SSH no Servidor

A primeira coisa a verificar é se o daemon do servidor SSH (sshd) está realmente em execução em sua máquina remota. Você geralmente precisará de acesso ao console (ex: através do console de um provedor de nuvem ou uma conexão física) para realizar essas verificações se o SSH estiver totalmente inacessível.

  1. Verificar o Status do Daemon SSH:
    Na maioria das distribuições Linux modernas (aquelas que usam systemd, como Ubuntu, CentOS 7+, Debian 8+):
    bash sudo systemctl status sshd
    Se o sshd não estiver em execução, a saída indicará inactive (dead) ou um status semelhante.

  2. Iniciar o Daemon SSH:
    Se o status estiver inativo, tente iniciar o serviço:
    bash sudo systemctl start sshd

  3. Habilitar o Daemon SSH para Iniciar na Inicialização:
    Para garantir que o SSH inicie automaticamente após uma reinicialização, habilite-o:
    bash sudo systemctl enable sshd

  4. Verificar os Logs do Daemon SSH:
    Se o sshd falhar ao iniciar, seus logs podem fornecer pistas cruciais. Para sistemas systemd:
    bash sudo journalctl -u sshd --since "10 minutes ago"
    Alternativamente, verifique os logs de autenticação gerais:
    bash sudo tail -f /var/log/auth.log # Ou para RHEL/CentOS: sudo tail -f /var/log/secure

Passo 2: Verificar as Regras do Firewall

Um firewall no lado do servidor é frequentemente o culpado pelas recusas de conexão. Ele pode estar bloqueando a porta SSH padrão (22) ou uma porta personalizada que você está tentando usar. Você precisa garantir que o firewall permita conexões de entrada na porta SSH.

  1. Identificar Seu Firewall:
    Firewalls comuns incluem:

    • UFW (Uncomplicated Firewall): Comum no Ubuntu/Debian.
    • firewalld: Comum no CentOS/RHEL 7+.
    • iptables: O firewall subjacente para Linux, configurado diretamente ou via front-ends.

  2. Verificar Status e Regras do Firewall:

    • UFW:
      bash sudo ufw status verbose
      Procure por regras que permitam tráfego na port 22 (ou sua porta SSH personalizada). Se o SSH estiver listado, certifique-se de que esteja como ALLOW (Permitir).
    • firewalld:
      bash sudo firewall-cmd --list-all
      Verifique as seções services e ports para ssh ou port 22/tcp.
    • iptables:
      bash sudo iptables -L -v -n
      A saída pode ser complexa. Procure por regras DROP ou REJECT relacionadas a tcp dpt:22 (ou sua porta personalizada) na cadeia INPUT.

  3. Permitir a Porta SSH Através do Firewall:

    • UFW:
      bash sudo ufw allow ssh # Permite a porta 22 # Ou, para uma porta personalizada (ex: 2222): sudo ufw allow 2222/tcp sudo ufw enable # Se o UFW estiver inativo
    • firewalld:
      bash sudo firewall-cmd --permanent --add-service=ssh # Ou, para uma porta personalizada (ex: 2222): sudo firewall-cmd --permanent --add-port=2222/tcp sudo firewall-cmd --reload
    • iptables:
      Adicionar regras iptables diretamente é mais complexo e temporário, a menos que sejam salvas. Geralmente, é recomendado usar firewalld ou ufw, se disponíveis. Para um teste rápido (não persistente):
      bash sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Você precisará salvar essas regras se quiser que persistam após a reinicialização.

    Aviso: Tenha cuidado ao modificar regras de firewall, especialmente ao acessar um servidor remoto via SSH. Regras incorretas podem bloquear seu acesso permanentemente. Sempre verifique se suas alterações funcionam antes de fechar sua sessão SSH atual, se tiver uma aberta.

Passo 3: Verificar a Configuração SSH (sshd_config)

O arquivo de configuração do daemon SSH (/etc/ssh/sshd_config) determina como o serviço opera. Configurações incorretas aqui podem levar ao bloqueio das conexões.

  1. Localizar sshd_config:
    O arquivo de configuração principal geralmente está localizado em /etc/ssh/sshd_config.

  2. Inspecionar Configurações Chave:
    Abra o arquivo com um editor de texto (ex: nano, vi):
    bash sudo nano /etc/ssh/sshd_config
    Procure pelas seguintes diretivas:

    • Port: Especifica a porta na qual o sshd está escutando. Certifique-se de que corresponde à porta à qual você está tentando se conectar a partir do seu cliente. Se estiver comentado (#), o padrão é a porta 22.
    • ListenAddress: Se presente, especifica em quais endereços IP o sshd deve escutar. Se estiver definido como um IP interno (ex: 127.0.0.1) e você estiver se conectando de uma rede externa, ele recusará a conexão. Para escutar em todas as interfaces, geralmente está comentado ou definido como 0.0.0.0 ou :: (para IPv6).
    • PermitRootLogin: Se definido como no, você não conseguirá fazer login como root. Embora não seja uma "conexão recusada" no sentido mais estrito (geralmente é uma permissão negada após a conexão), pode impedir tentativas de login bem-sucedidas.
    • PasswordAuthentication: Se definido como no, a autenticação por senha é desabilitada, exigindo autenticação baseada em chave.

    Dica: Após fazer qualquer alteração no sshd_config, você deve reiniciar o serviço SSH para que elas entrem em vigor:
    bash sudo systemctl restart sshd

Passo 4: Conectividade de Rede (Verificação Básica)

Embora um "connection refused" geralmente signifique que o servidor foi alcançado, é sempre bom confirmar rapidamente a acessibilidade básica da rede da sua máquina cliente para o endereço IP do servidor.

  1. Pingar o Servidor:
    Da sua máquina cliente, tente pingar o endereço IP ou hostname do servidor:
    bash ping <SERVER_IP_ADDRESS_OR_HOSTNAME>
    Se o ping falhar (perda de pacote de 100%), você tem um problema de rede mais fundamental (ex: IP incorreto, servidor desligado, problema de roteamento de rede) que precisa ser resolvido antes do SSH.

  2. Usar nc ou telnet (do cliente):
    Para testar se a porta está aberta e escutando da perspectiva do cliente:
    ```bash
    # Usando netcat (nc)
    nc -zv 22

    Usando telnet

    telnet 22
    `` Se oncmostrarConnection refusedou otelnet` for encerrado imediatamente, isso confirma que o servidor está rejeitando ativamente naquela porta, apontando de volta para o daemon SSH ou firewall.

Passo 5: Verificar SELinux ou AppArmor (Avançado)

Em alguns ambientes protegidos, ou após configurações personalizadas, o SELinux (Security-Enhanced Linux) ou o AppArmor podem estar impedindo o sshd de operar corretamente, especialmente se você estiver usando uma porta SSH não padrão.

  1. Verificar o Status do SELinux:
    bash sestatus
    Se o SELinux estiver em enforcing, talvez seja necessário ajustar suas políticas para permitir o sshd em uma porta personalizada.
    Por exemplo, para permitir a porta 2222 para SSH:
    bash sudo semanage port -a -t ssh_port_t -p tcp 2222 sudo systemctl restart sshd
    (Instale semanage se não estiver disponível: sudo apt install policycoreutils-python-utils no Debian/Ubuntu, sudo yum install policycoreutils-python no CentOS/RHEL).

  2. Verificar o Status do AppArmor:
    bash sudo aa status
    Se o AppArmor estiver em enforcing, revise seus logs (/var/log/syslog ou dmesg) em busca de quaisquer negações relacionadas ao sshd.

Passo 6: Revisar os Logs do Servidor (Novamente)

Após tentar os passos anteriores, sempre verifique novamente os logs do servidor em busca de novas mensagens de erro relacionadas ao sshd. Esta é sua fonte final de verdade sobre o que o servidor está enfrentando.

  • sudo journalctl -u sshd
  • sudo tail -f /var/log/auth.log (ou /var/log/secure)

Procure por mensagens indicando por que o serviço pode não estar iniciando, por que as conexões estão sendo descartadas ou qualquer outra informação relevante.

Melhores Práticas para Prevenir Problemas Futuros

  • Atualize Regularmente Seu SO: Mantenha o sistema operacional e os pacotes do seu servidor, incluindo o openssh-server, atualizados.
  • Teste as Regras do Firewall: Após implementar ou modificar as regras do firewall, teste-as sempre imediatamente.
  • Faça Backup do sshd_config: Antes de fazer alterações em /etc/ssh/sshd_config, faça um backup (sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak).
  • Use um Console de Gerenciamento: Para instâncias em nuvem, saiba como acessar o console do servidor (ex: AWS EC2 Serial Console, Google Cloud Console) para solucionar problemas de rede quando o SSH estiver indisponível.
  • Monitore os Logs: Revise regularmente os logs auth.log ou secure em busca de atividade incomum ou erros persistentes.

Conclusão

O erro 'Connection Refused', embora frustrante, geralmente é simples de resolver verificando sistematicamente o status do daemon SSH, as regras do firewall e o arquivo sshd_config. Ao seguir as etapas descritas neste guia, você pode diagnosticar eficientemente a causa raiz e restaurar seu acesso remoto seguro. Lembre-se de sempre aplicar as alterações com cautela e verificar a funcionalidade para evitar o bloqueio de acesso ao seu servidor.

Com estas técnicas de solução de problemas, você estará bem equipado para lidar com problemas de conexão SSH e manter um controle contínuo sobre seus sistemas remotos. Boas sessões SSH!