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

Falhas de SSH são mais fáceis de corrigir quando você separa problemas de transporte de problemas de autenticação. Conexão recusada significa que seu cliente SSH alcançou um host, mas nada aceitou a conexão TCP naquela porta. Permissão negada significa que o servidor SSH respondeu, mas rejeitou seu login. São incidentes diferentes, mesmo que ambos pareçam "Não consigo entrar".

Mantenha uma sessão SSH ativa aberta enquanto altera as configurações do servidor. A maioria das interrupções dolorosas de SSH acontece quando alguém edita /etc/ssh/sshd_config, reinicia o serviço, desconecta e só então descobre que a nova configuração bloqueia todos os caminhos de login.

Entendendo os Erros: Recusado vs. Negado

Leia a mensagem exata do cliente antes de alterar qualquer coisa:

Conexão recusada: o host rejeitou ativamente a conexão TCP, geralmente porque o sshd não está ouvindo naquela porta ou um firewall a está rejeitando.
Tempo limite de conexão excedido: os pacotes estão sendo descartados ou o caminho de rede está quebrado. Isso é mais provável de ser um firewall, rota, VPN, grupo de segurança ou IP errado.
Permissão negada (publickey): o servidor está acessível, mas não aceitou sua chave.
Permissão negada (publickey,password): o servidor tentou um ou mais métodos de autenticação e os rejeitou.
Falha na verificação da chave do host: seu cliente não confia na identidade do servidor atualmente apresentada para aquele nome de host ou IP.

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

ssh: connect to host example port 22: Connection refused geralmente aponta para o host ou porta remota. A máquina respondeu, mas o SSH não estava aceitando conexões lá.

1. Verifique o Status do Daemon SSH (sshd)

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

Passos Acionáveis (no servidor remoto):

Em muitas distribuições Linux, o serviço é chamado sshd; no Debian e Ubuntu, geralmente é chamado ssh. Tente aquele que seu sistema usa:

systemctl status sshd
systemctl status ssh

Se o serviço estiver inativo ou falhou, inicie-o:

sudo systemctl start sshd
sudo systemctl enable sshd

Se o sshd falhar ao iniciar após uma alteração de configuração, valide a configuração:

sudo sshd -t

Esse comando é uma das verificações mais seguras que você pode executar antes de reiniciar o SSH.

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

Por padrão, o SSH usa a porta TCP 22, mas muitos servidores usam uma porta diferente. Se o servidor ouvir na porta 2222, o comando do cliente deve incluí-la:

ssh -p 2222 [email protected]

A. Revise o `sshd_config`

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

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

Após editar o arquivo, execute sudo sshd -t antes de recarregar. Se a sintaxe for válida, recarregue ou reinicie o serviço. Recarregar geralmente é menos disruptivo:

sudo systemctl reload sshd

B. Verifique os Sockets de Escuta

Use ss para confirmar que o sshd está ouvindo:

sudo ss -tuln | grep 22

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

Se o SSH ouvir apenas em 127.0.0.1:22, clientes remotos não poderão conectar. Se ouvir em 0.0.0.0:22 ou em um endereço de interface privada específico, o acesso remoto pode ser possível dependendo das regras de firewall.

3. Verificações de Firewall e Rede

Um firewall que descarta pacotes geralmente causa um tempo limite. Um firewall que rejeita pacotes pode causar uma recusa. Verifique tanto o firewall do host quanto qualquer firewall de rede fora do host.

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

Garanta que o tráfego SSH seja permitido:

# Verifique o status atual
sudo ufw status

# Permita tráfego na porta padrão 22
sudo ufw allow ssh
# OU pelo número da porta
sudo ufw allow 22/tcp

# Recarregue as regras do firewall
sudo ufw reload

Grupos de segurança em nuvem, ACLs de rede, rotas VPN e firewalls de escritório podem bloquear o SSH antes que o tráfego chegue ao servidor. Se o sshd estiver ouvindo e o firewall do host estiver aberto, teste de uma máquina dentro da mesma rede privada. Isso informa se o problema é local ao servidor ou em algum lugar ao longo do caminho externo.

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

Se o servidor responder com Permissão negada, o caminho de rede está funcionando. Concentre-se no nome de usuário, métodos de autenticação permitidos, chaves, estado da conta e permissões de arquivo.

1. Verifique Nome de Usuário e Senha

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

Nome de usuário: Imagens de nuvem geralmente usam usuários específicos como ubuntu, ec2-user, admin, debian ou rocky. root pode estar desabilitado.
Senha: Se a autenticação por senha estiver habilitada, verifique erros de digitação, bloqueio de conta, senhas expiradas e regras PAM.
Porta e host: Um número surpreendente de falhas de autenticação é causado pela conexão ao servidor errado que por acaso executa SSH.

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

ssh -vvv usuario@hostname

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

2. Falhas de Autenticação Baseada em Chave

A autenticação por chave falha quando o cliente oferece a chave privada errada, o servidor não tem a chave pública correspondente, as permissões estão muito abertas ou o sshd_config bloqueia o login.

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

O SSH é extremamente rigoroso quanto às permissões de arquivo por segurança. Se as permissões estiverem 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 corretas, 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

Verifique também a propriedade:

chown -R "$USER:$USER" ~/.ssh

No servidor, StrictModes geralmente está habilitado. Se o diretório home, o diretório .ssh ou o arquivo authorized_keys for gravável por outros usuários, o sshd pode ignorar a chave.

B. Chave Não Presente ou Formatada Incorretamente

Garanta que a chave pública esteja no ~/.ssh/authorized_keys do usuário alvo, uma chave por linha. A chave privada permanece no seu cliente. Não cole a chave privada no authorized_keys.

Do cliente, force uma chave específica durante a depuração:

ssh -i ~/.ssh/id_ed25519 -vvv [email protected]

Na saída verbose, procure por linhas mostrando quais chaves foram oferecidas e por que o servidor as aceitou ou rejeitou.

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

# Garanta que a autenticação por senha não esteja desabilitada se você depende de senhas
PasswordAuthentication yes

Se AllowUsers, AllowGroups, DenyUsers ou DenyGroups estiverem presentes, eles podem substituir o que parece ser uma configuração de chave válida. Um usuário com a chave correta ainda pode ser bloqueado por essas diretivas.

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

Os logs do servidor geralmente informam o motivo real de uma negação. Mantenha um terminal aberto no servidor e observe os logs enquanto tenta um login do cliente.

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 SSH geral
sudo tail -f /var/log/secure

Em sistemas com journaling systemd, isso geralmente é mais fácil:

sudo journalctl -u sshd -f
sudo journalctl -u ssh -f

As mensagens de log podem mostrar "propriedade ou modos ruins", "usuário não permitido", "usuário inválido", "autenticação recusada" ou falhas de conta PAM. Essas mensagens são mais confiáveis do que adivinhar apenas do lado do cliente.

Falhas de verificação de chave do host

Falha na verificação da chave do host não é o mesmo que uma senha ou chave ruim. Significa que seu cliente tem uma identidade de servidor salva para aquele nome de host ou IP, e o servidor está agora apresentando uma identidade diferente. Isso pode acontecer após uma reconstrução, reutilização de IP, alteração de balanceador de carga ou um risco real de homem-no-meio.

Não exclua cegamente o aviso em um ambiente de produção. Verifique a impressão digital do servidor através do seu console de nuvem, gerenciamento de configuração ou um canal confiável existente. Depois de saber que a mudança é esperada, remova a entrada antiga:

ssh-keygen -R exemplo.com
ssh-keygen -R 192.0.2.10

Em seguida, conecte-se novamente e aceite a nova chave do host somente se a impressão digital corresponder ao que você espera.

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

Use pares de chaves: Desabilite a autenticação por senha somente depois de testar o acesso por chave em uma segunda sessão.
Limite quem pode fazer login: Use AllowUsers ou AllowGroups quando apropriado, mas documente para que operadores futuros não persigam falsos problemas de permissão.
Use PermitRootLogin no: Prefira usuários normais com sudo.
Faça backup da configuração: Antes de alterar /etc/ssh/sshd_config, copie-o:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) ``` 5. Valide antes de recarregar: Execute sudo sshd -t. 6. Mantenha um caminho de emergência: Para servidores em nuvem, saiba como usar o console serial, modo de resgate, recurso de conexão de instância ou gerenciamento de configuração se o SSH quebrar.

O caminho mais curto através da solução de problemas de SSH é: identifique o erro exato, prove se o servidor está ouvindo, prove se o caminho de rede alcança essa porta, então leia os logs do servidor para falhas de autenticação. Adivinhar geralmente leva mais tempo do que executar essas verificações em ordem.