Resolução de Problemas Comuns de SSH: Conexão Recusada e Permissão Negada

Secure Shell (SSH) é a base da administração de sistemas remotos, fornecendo comunicação criptografada para acessar servidores. No entanto, encontrar erros de conexão pode interromper a produtividade imediatamente. Os dois erros mais comuns e frustrantes que os usuários enfrentam são "Conexão Recusada" e "Permissão Negada".

Este guia irá levá-lo através de uma abordagem sistemática para diagnosticar e resolver esses problemas. Ao entender as causas típicas — desde obstruções de rede até configurações de autenticação incorretas — você pode restaurar rapidamente o acesso seguro às suas máquinas remotas. Abordaremos verificações essenciais, desde a verificação do status do servidor até a depuração de mecanismos de autenticação.

Entendendo os Erros: Recusada vs. Negada

É crucial diferenciar entre as duas mensagens de erro primárias, pois elas apontam para causas-raiz muito diferentes:

Conexão Recusada (Connection Refused): Isso geralmente significa que a conexão de rede alcançou o servidor, mas nada estava ouvindo na porta especificada, ou o sistema operacional rejeitou ativamente a tentativa de conexão.
Permissão Negada (Permission Denied): Isso implica que o serviço SSH (sshd) recebeu com sucesso a solicitação de conexão, mas a tentativa de autenticação (senha ou chave) falhou com base na configuração do servidor.

Parte 1: Resolução de Problemas de Conexão Recusada

"Conexão Recusada" (frequentemente vista como ssh: connect to host <hostname> port 22: Connection refused) geralmente aponta para um problema no lado do servidor que impede o daemon de aceitar conexões de entrada.

1. Verificar o Status do Daemon SSH (sshd)

A causa mais comum para a recusa é que o processo do servidor SSH não está em execução ou falhou.

Etapas Acionáveis (no servidor remoto):

Verifique o status do serviço usando systemctl (comum em distribuições Linux modernas):

systemctl status sshd

Se o status mostrar inactive ou failed, inicie o serviço:

sudo systemctl start sshd
# Habilite-o para iniciar automaticamente na inicialização
sudo systemctl enable sshd

2. Verificar a Porta de Escuta e a Configuração

Por padrão, o SSH é executado na porta TCP 22. Se a porta foi alterada para reforço de segurança, você deve especificar a porta correta ao se conectar ou garantir que o servidor esteja ouvindo na porta esperada.

A. Revisar `sshd_config`

Examine o arquivo de configuração do SSH, geralmente localizado em /etc/ssh/sshd_config. Procure pela diretiva Port:

# /etc/ssh/sshd_config example
Port 2222  # Se esta não for 22, você precisará especificá-la no lado do cliente

Se você alterar este arquivo, você deve reiniciar o serviço sshd para que as alterações entrem em vigor.

B. Verificar Sockets de Escuta

Use ss ou netstat para confirmar se o sshd está ativamente ouvindo na interface e porta esperadas. Verificamos a porta 22 aqui:

# Usando ss (preferencial em sistemas modernos)
sudo ss -tuln | grep 22

# Saída esperada mostrando o status de escuta:
# LISTEN 0      128    0.0.0.0:22               0.0.0.0:*

Se nada aparecer para a porta 22, o daemon não está em execução ou está configurado para ouvir em um endereço/porta diferente.

3. Verificações de Firewall e Rede

Um firewall que bloqueia o tráfego antes que ele chegue ao processo sshd geralmente resultará em um tempo limite, mas às vezes pode se apresentar como uma recusa. É essencial confirmar as regras de firewall no lado do servidor.

Comandos Comuns de Firewall (UFW no Ubuntu/Debian):

Certifique-se de que o tráfego SSH é permitido:

# Verificar status atual
sudo ufw status

# Permitir tráfego na porta padrão 22
sudo ufw allow ssh
# OU por número de porta
sudo ufw allow 22/tcp

# Recarregar regras do firewall
sudo ufw reload

⚠️ Aviso sobre Firewalls Externos: Se você estiver se conectando de uma rede remota, certifique-se de que quaisquer dispositivos de rede intermediários, grupos de segurança na nuvem (como AWS Security Groups ou Azure NSGs) ou firewalls de hardware estejam explicitamente permitindo o tráfego na porta SSH.

Parte 2: Resolução de Problemas de Permissão Negada

Se você se conectar com sucesso ao servidor, mas receber imediatamente "Permission denied (publickey,password)", o problema reside estritamente na autenticação.

1. Verificar Nome de Usuário e Senha

Esta é a verificação mais simples, mas frequentemente negligenciada:

Nome de Usuário: Você está usando o nome de usuário correto para o sistema de destino? O login de root pode estar desabilitado.
Senha: Se estiver usando autenticação por senha, verifique o Caps Lock, erros de digitação e certifique-se de que a conta não esteja bloqueada.

Verificação no Lado do Cliente: Para ver a saída de depuração detalhada, execute seu cliente com flags verbosas:

ssh -vvv user@hostname

Esta saída mostrará claramente quais métodos de autenticação o cliente tentou e quais o servidor rejeitou.

2. Falhas na Autenticação Baseada em Chave

A autenticação baseada em chave é superior, mas erros de configuração são causas frequentes de negação.

A. Permissões Incorretas no Diretório `.ssh`

O SSH é extremamente rigoroso quanto às permissões de arquivo por motivos de segurança. Se as permissões forem muito abertas, o servidor ignorará o arquivo de chave completamente.

No Servidor Remoto (Corrigindo Permissões):

# As permissões do diretório home do usuário geralmente estão bem, mas verifique a pasta .ssh
chmod 700 ~/.ssh

# O arquivo authorized_keys deve ser gravável apenas pelo proprietário
chmod 600 ~/.ssh/authorized_keys

B. Chave Ausente ou Formatada Incorretamente

Certifique-se de que sua chave pública (id_rsa.pub ou similar) esteja corretamente anexada ao arquivo ~/.ssh/authorized_keys do servidor para o usuário de destino. Cada chave deve estar em sua própria linha, sem quebras de linha inseridas no meio da string da chave.

C. Configuração do Servidor Desabilitando Chaves

Verifique /etc/ssh/sshd_config no servidor para garantir que a autenticação por chave seja permitida:

PubkeyAuthentication yes

# Certifique-se de que a autenticação por senha não esteja desabilitada se você depender de senhas
PasswordAuthentication yes

3. Investigação de Logs do Lado do Servidor

Quando a autenticação falha, os logs do servidor são a fonte definitiva da verdade. Procure por mensagens relacionadas à tentativa de login falha.

Locais Comuns de Log:

Debian/Ubuntu: /var/log/auth.log
RHEL/CentOS/Fedora: /var/log/secure

Use grep para filtrar tentativas de conexão recentes:

# Em sistemas RHEL/CentOS
sudo grep 'Failed password' /var/log/secure

# Ou procure por atividade geral do SSH
sudo tail -f /var/log/secure

As mensagens de log frequentemente declaram explicitamente por que a chave foi rejeitada (por exemplo, opções inválidas, nenhuma chave correspondente encontrada ou contexto de usuário incorreto).

Resumo das Melhores Práticas para Acesso SSH Confiável

Use Pares de Chaves: Desabilite a autenticação por senha (PasswordAuthentication no) em sshd_config assim que o acesso por chave for verificado.
Altere a Porta Padrão: Mover o SSH da porta 22 reduz o ruído de varreduras automatizadas.
Use PermitRootLogin no: Force o acesso administrativo através de usuários padrão, forçando o uso de sudo.
Backup da Configuração: Antes de fazer alterações significativas em /etc/ssh/sshd_config, sempre faça backup do arquivo original:
bash sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
Teste Localmente: Após as alterações de configuração, teste a conectividade localmente no servidor (se possível) antes de desconectar sua sessão ativa para evitar se trancar para fora.

Ao verificar sistematicamente o status do serviço, o caminho da rede e as camadas de configuração de autenticação, você pode resolver rapidamente os frustrantes erros de Connection Refused e Permission Denied inerentes à gestão de acesso remoto.