Domine Ferramentas e Melhores Práticas de DevOps - Hub de Conhecimento DevOps Domine Ferramentas e Melhores Práticas de DevOps - Hub de Conhecimento DevOps

Corrigindo Rapidamente Erros de Conexão Recusada no SSH

Corrija erros de conexão recusada no SSH verificando o status do sshd, portas, regras de firewall, sshd_config, SELinux e logs do servidor.

Corrigindo Rapidamente Erros de Conexão Recusada no SSH

O SSH (Secure Shell) é a espinha dorsal da administração remota 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-o de acessar seus sistemas cruciais.

Este artigo fornece um guia abrangente e 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-o com o conhecimento e os comandos para recuperar rapidamente o acesso aos seus servidores.

Entendendo o Erro 'Conexão Recusada'

Quando você recebe um erro Connection refused, isso significa que seu cliente SSH alcançou com sucesso o servidor remoto, 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 "recusado" aponta diretamente para um problema no lado do servidor que está impedindo ativamente 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 'Conexão Recusada'

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 falhado, sido interrompido ou não iniciado na inicialização.
  • Firewall Bloqueando a Porta 22 (ou porta personalizada): O firewall do servidor (por exemplo, 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 Comuns para 'Recusado'): Embora menos provável para um erro "recusado", um problema fundamental de rede pode, às vezes, se manifestar inesperadamente.
  • Restrições do SELinux ou AppArmor: Aprimoramentos 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 de Solução de Problemas Passo a Passo

Vamos mergulhar nas etapas práticas para diagnosticar e corrigir o erro 'Conexão Recusada'.

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. Normalmente, você precisará de acesso ao console (por exemplo, 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+):
    sudo systemctl status sshd

No Debian/Ubuntu, o serviço pode ser nomeado ssh:

sudo systemctl status ssh ``` Se o sshd não estiver em execução, a saída indicará inactive (dead) ou um status semelhante.

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

Ou no Debian/Ubuntu:

sudo systemctl start ssh ```

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

Ou no Debian/Ubuntu:

sudo systemctl enable ssh ```

  1. Verificar os Logs do Daemon SSH: Se o sshd falhar ao iniciar, seus logs podem fornecer pistas cruciais. Para sistemas systemd:
    sudo journalctl -u sshd --since "10 minutes ago"

Ou, se sua distro usar a unidade ssh:

sudo journalctl -u ssh --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 do lado do servidor é frequentemente o culpado por 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 através de interfaces.

  2. Verificar o Status e as Regras do Firewall:

    • UFW:
      sudo ufw status verbose
      Procure por regras permitindo tráfego na porta 22 (ou sua porta SSH personalizada). Se o SSH estiver listado, certifique-se de que está ALLOW (permitido).
    • firewalld:
      sudo firewall-cmd --list-all
      Verifique as seções services e ports para ssh ou porta 22/tcp.
    • iptables:
      sudo iptables -L -v -n
      Esta 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:
      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:
      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):
      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 reinicializações.

    Aviso: Tenha cuidado ao modificar regras de firewall, especialmente ao fazer SSH em um servidor remoto. Regras incorretas podem bloqueá-lo permanentemente. Sempre verifique se suas alterações funcionam antes de fechar sua sessão SSH atual, se você tiver uma aberta.

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

O arquivo de configuração do daemon SSH (/etc/ssh/sshd_config) dita como o serviço opera. Configurações incorretas aqui podem levar a conexões serem recusadas.

  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):

    sudo nano /etc/ssh/sshd_config

    Procure pelas seguintes diretivas:

    • Port: Especifica a porta em que o sshd escuta. Certifique-se de que corresponde à porta que você está tentando conectar do seu cliente. Se estiver comentada (#), o padrão é a porta 22.
    • ListenAddress: Se presente, especifica quais endereços IP o sshd deve escutar. Se estiver definido para um IP interno (ex.: 127.0.0.1) e você estiver conectando de uma rede externa, ele recusará a conexão. Para escutar em todas as interfaces, geralmente é comentado ou definido como 0.0.0.0 ou :: (para IPv6).
    • PermitRootLogin: Se definido como no, você não poderá fazer login como root. Embora não seja uma "conexão recusada" no sentido estrito (muitas vezes é 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:

    sudo systemctl restart sshd

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

Embora uma "conexão recusada" normalmente 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. Ping no Servidor: Da sua máquina cliente, tente pingar o endereço IP ou nome do host do servidor:

    ping <SERVER_IP_ADDRESS_OR_HOSTNAME>

    Se o ping falhar (100% de perda de pacotes), você tem um problema de rede mais fundamental (ex.: IP incorreto, servidor offline, 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 ouvindo da perspectiva do cliente:

    # Usando netcat (nc)
nc -zv <SERVER_IP_ADDRESS> 22

# Usando telnet
telnet <SERVER_IP_ADDRESS> 22

    Se nc mostrar Connection refused ou telnet sair imediatamente, confirma que o servidor está rejeitando ativamente nessa porta, apontando de volta para o daemon SSH ou firewall.

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

Em alguns ambientes reforçados, ou após configurações personalizadas, o SELinux (Security-Enhanced Linux) ou 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:

    sestatus

    Se o SELinux estiver enforcing, você pode precisar ajustar suas políticas para permitir o sshd em uma porta personalizada. Por exemplo, para permitir a porta 2222 para SSH:

    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-utils ou o pacote correspondente para sua versão da família RHEL).

  2. Verificar o Status do AppArmor:

    sudo aa status

    Se o AppArmor estiver enforcing, revise seus logs (/var/log/syslog ou dmesg) para quaisquer negações relacionadas ao sshd.

Passo 6: Revisar os Logs do Servidor (Novamente)

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

  • 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 do seu servidor e os pacotes, incluindo openssh-server, atualizados.
  • Teste as Regras do Firewall: Após implementar ou modificar regras de firewall, teste-as imediatamente.
  • Faça Backup do sshd_config: Antes de fazer alterações no /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 para atividades incomuns ou erros persistentes.

Conclusão Final

Um erro de conexão SSH recusada geralmente significa que o servidor está acessível, mas nada está aceitando sua conexão nessa porta. Verifique o nome do serviço SSH para sua distribuição, confirme se a porta está ouvindo, abra o firewall, valide o sshd_config e leia os logs antes de fazer alterações maiores. Se você ainda tiver uma sessão de trabalho aberta, mantenha-a aberta até que um novo login seja bem-sucedido.