Diagnosticando e Resolvendo Falhas de Autenticação SSH

O Secure Shell (SSH) é a base da administração remota segura, permitindo acesso criptografado a servidores e dispositivos de rede. No entanto, encontrar falhas de autenticação é uma experiência comum e muitas vezes frustrante para administradores de sistemas e desenvolvedores. Esses problemas podem ter diversas causas, desde simples erros de digitação até problemas complexos de permissão ou configurações incorretas.

Este artigo serve como um guia abrangente para diagnosticar e resolver falhas de autenticação SSH de forma eficaz. Vamos nos aprofundar em métodos sistemáticos de solução de problemas, enfatizando o papel crítico da saída detalhada do lado do cliente e da análise de logs do lado do servidor. Ao entender como interpretar essas pistas de diagnóstico, você estará preparado para identificar a causa raiz da maioria dos problemas de autenticação e restaurar seu acesso remoto seguro.

Entendendo os Métodos de Autenticação SSH

Antes de mergulhar na solução de problemas, é essencial entender os principais métodos de autenticação que o SSH utiliza:

Autenticação por Senha: O usuário fornece uma senha, que o servidor verifica em seu banco de dados de usuários ou em um serviço de autenticação externo (como PAM).
Autenticação por Chave Pública: Este método mais seguro usa um par de chaves criptográficas: uma chave privada armazenada no cliente e uma chave pública correspondente armazenada no servidor. Ao autenticar, o cliente usa sua chave privada para provar sua identidade sem nunca enviar a chave privada pela rede.

Falhas de autenticação podem ocorrer com qualquer um dos métodos, mas as etapas de solução de problemas geralmente diferem.

Verificações Iniciais e Armadilhas Comuns

Antes de mergulhar em logs detalhados, é prudente realizar algumas verificações básicas, pois muitos problemas são frequentemente descuidos simples:

Nome de Usuário e Hostname Corretos: Verifique novamente se você está usando o nome de usuário correto e o hostname ou endereço IP exato do servidor de destino.
Conectividade de Rede: Você consegue alcançar o servidor? Use nc -vz host 22 ou ssh -vvv para testar a acessibilidade SSH. O ping pode ajudar, mas muitos servidores bloqueiam ICMP mesmo quando o SSH está funcionando.
```
ping example.com
```

Status do Serviço SSH: O servidor SSH (sshd) está realmente em execução na máquina de destino? Se você tiver acesso ao console, verifique seu status.

sudo systemctl status sshd # Para sistemas baseados em systemd (maioria dos Linux modernos)
sudo service sshd status    # Para sistemas init mais antigos

Porta SSH: O daemon SSH está ouvindo na porta padrão (22) ou em uma porta personalizada? Se for uma porta personalizada, você precisará especificá-la com -p.
Regras de Firewall: Existem firewalls (do lado do cliente ou do servidor) bloqueando a porta 22 (ou sua porta SSH personalizada)? Verifique firewalls do servidor como ufw, firewalld ou grupos de segurança da AWS.
```
sudo ufw status
sudo firewall-cmd --list-all
```

Diagnóstico do Lado do Cliente: Aproveitando o Modo Detalhado

O cliente SSH oferece modos detalhados (-v, -vv, -vvv) que fornecem saída de depuração detalhada sobre o processo de conexão e tentativas de autenticação. Essa saída é inestimável para entender por que o cliente acha que a autenticação está falhando.

Usando Flags Detalhadas

-v: Saída detalhada.
-vv: Saída mais detalhada.
-vvv: Saída ainda mais detalhada (geralmente a mais útil para problemas de autenticação).

Comando de Exemplo:

ssh -vvv usuario@ip_do_servidor

Interpretando a Saída Detalhada

Ao executar ssh no modo detalhado, procure por linhas-chave que indicam onde o processo de autenticação está falhando:

debug1: Authentications that can continue:: Esta linha informa quais métodos de autenticação o servidor está disposto a aceitar. Se o método desejado (por exemplo, publickey) não estiver listado, a configuração do servidor está impedindo.
```
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
```
debug1: Offering public key:: Isso indica que seu cliente está tentando usar uma chave pública específica para autenticação. Se você espera autenticação por chave pública, mas não vê isso, seu cliente não está encontrando ou oferecendo a chave.
```
debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
```
debug3: send_pubkey_test: ... trying private key: /home/user/.ssh/id_rsa: Isso confirma que o cliente está tentando usar uma chave privada específica.
debug1: Server accepts key: ...: Isso indicaria autenticação bem-sucedida por chave pública da perspectiva do cliente. Se você não vir isso, a chave provavelmente foi rejeitada pelo servidor.
debug1: No more authentication methods to try.: Isso geralmente aparece antes de um erro Permission denied e significa que o cliente esgotou todos os métodos de autenticação disponíveis sem sucesso.
debug1: Permission denied (publickey,password).: Este é o erro final do lado do cliente, resumindo a rejeição de todas as tentativas pelo servidor.

Dica: Preste muita atenção à ordem dos métodos de autenticação oferecidos e aceitos. Se publickey for oferecido, mas imediatamente seguido por um prompt de senha, geralmente significa que o servidor rejeitou a chave pública.

Diagnóstico do Lado do Servidor: Examinando Logs do Servidor SSH

Enquanto a saída detalhada do lado do cliente mostra o que o cliente está tentando fazer, os logs do servidor fornecem informações definitivas sobre por que o servidor rejeitou a tentativa de autenticação. Esta é frequentemente a etapa mais crítica na análise de causa raiz.

Localizando Logs do Servidor SSH

A localização dos logs do servidor SSH varia de acordo com o sistema operacional:

Debian/Ubuntu e derivados: /var/log/auth.log
RHEL/CentOS/Fedora e derivados: /var/log/secure
Sistemas baseados em systemd (maioria dos Linux modernos): Você também pode usar journalctl.

Visualizando e Filtrando Logs do Servidor

Use ferramentas como tail ou journalctl para monitorar logs em tempo real ou filtrar entradas específicas do SSH.

Comandos de Exemplo:

# Para Debian/Ubuntu
sudo tail -f /var/log/auth.log | grep sshd

# Para RHEL/CentOS
sudo tail -f /var/log/secure | grep sshd

# Para sistemas baseados em systemd (maneira mais robusta de visualizar logs atuais)
sudo journalctl -u sshd -f

# Para visualizar todos os logs do sshd desde o início (útil se a falha ocorreu antes)
sudo journalctl -u sshd

Entradas Comuns de Log do Servidor e Seus Significados

Procure por mensagens relacionadas a sshd quando você tentar se conectar. Aqui estão algumas entradas comuns que indicam falhas de autenticação:

Failed password for user from IP port ssh2: Indica que uma tentativa de autenticação por senha falhou. Isso pode ser devido a uma senha incorreta ou se o usuário não tem permissão para fazer login via senha.
Authentication refused: bad ownership or modes for directory /home/user/.ssh: Este é um erro muito comum de autenticação por chave pública. O diretório .ssh no servidor tem permissões incorretas.
- Solução: chmod 700 /home/user/.ssh
Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys: Outro erro comum de chave pública, indicando que o arquivo authorized_keys tem permissões incorretas.
- Solução: chmod 600 /home/user/.ssh/authorized_keys
sshd[PID]: error: Permissions 0777 for '/home/user/.ssh/authorized_keys' are too open.: Declara explicitamente o problema com modos de arquivo excessivamente permissivos. O SSH é muito rigoroso com permissões por razões de segurança.
User username from IP not allowed because not listed in AllowUsers: O usuário não tem permissão para fazer login via SSH de acordo com a diretiva AllowUsers em /etc/ssh/sshd_config.
User username from IP not allowed because listed in DenyUsers: O usuário tem explicitamente negado o acesso SSH por DenyUsers.
input_userauth_request: invalid user username: O nome de usuário fornecido não existe no servidor.
Failed publickey for user ou chaves oferecidas repetidamente seguidas por senha: a chave pública apresentada pelo cliente não correspondeu a uma chave aceita para aquele usuário, ou o servidor recusou a chave devido a permissões ou política.
Maximum authentication attempts exceeded for user from IP: O cliente tentou muitos métodos de autenticação ou enviou muitas credenciais incorretas. Controlado por MaxAuthTries em sshd_config.
Connection closed by authenticating user IP port 22 [preauth]: Isso pode ocorrer se nenhum método de autenticação aceitável foi encontrado, ou se o cliente fecha abruptamente a conexão após uma falha.

Cenários Comuns de Falha de Autenticação e Soluções

Vamos categorizar falhas comuns e seus remédios específicos.

1. Falhas de Autenticação por Senha

Senha Incorreta: O problema mais direto. Verifique sua senha novamente. Esteja ciente dos layouts de teclado, Caps Lock ou Num Lock.
Usuário Não Permitido: O arquivo sshd_config (/etc/ssh/sshd_config) pode restringir o login para certos usuários.
- PermitRootLogin no: Impede o login root (altamente recomendado para segurança).
- AllowUsers usuario1 usuario2: Apenas usuários especificados podem fazer login.
- DenyUsers usuario: Usuários especificados não podem fazer login.
- AllowGroups nome_do_grupo: Apenas usuários em grupos especificados podem fazer login.
- Solução: Ajuste as diretivas do sshd_config e reinicie o sshd.
Problemas com PAM: Se o servidor usa Pluggable Authentication Modules (PAM), problemas com a configuração do PAM podem impedir a autenticação por senha. Verifique /var/log/auth.log para erros específicos do PAM. Isso é menos comum para configurações SSH básicas.

2. Falhas de Autenticação por Chave Pública

A autenticação por chave pública é geralmente mais segura, mas propensa a mais erros relacionados à configuração.

Permissões Incorretas de Arquivo/Diretório (Lado do Servidor): Esta é de longe a causa mais comum. O SSH exige permissões estritas para ~/.ssh e ~/.ssh/authorized_keys por segurança.
- ~: O diretório home do usuário não deve ser gravável por todos (chmod 755 ~ geralmente é seguro).
- ~/.ssh: Deve ser 700 (rwx apenas para o proprietário).
```
chmod 700 ~/.ssh
```
- ~/.ssh/authorized_keys: Deve ser 600 (rw apenas para o proprietário).
```
chmod 600 ~/.ssh/authorized_keys
```
- O proprietário desses arquivos e diretórios deve ser o usuário que está tentando fazer login.
```
sudo chown -R usuario:usuario ~/.ssh
```
Conteúdo Incorreto de authorized_keys: A chave pública em ~/.ssh/authorized_keys pode estar corrompida, ter caracteres extras ou estar em um formato incorreto. Cada chave deve estar em uma única linha. Uma maneira rápida de garantir o formato adequado é usar ssh-copy-id do cliente.
```
ssh-copy-id -i ~/.ssh/id_rsa.pub usuario@ip_do_servidor
```
Para verificar a impressão digital da sua chave pública no lado do cliente, use: ssh-keygen -l -f ~/.ssh/id_rsa.pub
Cliente Não Oferecendo Chave: A chave privada pode não estar no local padrão (~/.ssh/id_rsa), não carregada no ssh-agent, ou você não a especificou com -i.
- Solução: Certifique-se de que sua chave privada seja id_rsa (ou id_ed25519, etc.) em ~/.ssh e tenha permissões 600. Se não, especifique-a:
```
ssh -i /caminho/para/sua/chave_privada usuario@ip_do_servidor
```
- Se estiver usando ssh-agent, certifique-se de que sua chave foi adicionada:
```
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/sua_chave_privada
```
sshd_config Desabilitando Autenticação por Chave Pública: O daemon SSH do servidor pode estar configurado para desabilitar a autenticação por chave pública.
- Verifique PubkeyAuthentication yes em /etc/ssh/sshd_config.
- Verifique AuthorizedKeysFile .ssh/authorized_keys para garantir que aponte para o arquivo correto. O padrão geralmente é suficiente.
- Solução: Defina PubkeyAuthentication yes e reinicie o sshd.
Interferência do SELinux/AppArmor: Em sistemas com SELinux ou AppArmor, esses módulos de segurança podem às vezes bloquear o SSH de acessar diretórios home do usuário ou arquivos .ssh, mesmo que as permissões de arquivo estejam corretas. Verifique logs de auditoria (/var/log/audit/audit.log ou sudo ausearch -m AVC -ts recent) para pistas. Este é um cenário avançado.

3. Conexão Recusada ou Timeout

Embora não sejam estritamente falhas de "autenticação", elas geralmente precedem as tentativas de autenticação e impedem que elas comecem.

Firewall Bloqueando: Verifique firewalls tanto no cliente (por exemplo, firewall do SO local) quanto no servidor (por exemplo, ufw, firewalld, grupos de segurança em nuvem, ACLs de rede). Certifique-se de que a porta 22 (ou porta personalizada) esteja aberta.
Servidor SSH Não Executando: O serviço sshd pode não estar ativo ou ter falhado.
Porta/IP Incorretos: Tentar conectar-se à porta ou endereço IP errado.

Dicas Gerais de Depuração

Verifique sshd_config: Sempre revise /etc/ssh/sshd_config no servidor em busca de configurações não padrão que possam estar interferindo. Após fazer alterações, sempre reinicie o daemon SSH: sudo systemctl restart sshd (ou sudo service sshd restart).
Teste com um Novo Usuário/Chave: Se possível, crie um novo usuário e um novo par de chaves pública/privada. Tente autenticar com esta configuração nova. Se funcionar, o problema é específico da configuração do usuário original.
Isole o Problema: Tente conectar-se de uma máquina cliente diferente. Se funcionar, o problema é específico do cliente. Se falhar de vários clientes, o problema é específico do servidor.
Aumente o LogLevel (Lado do Servidor): Para depuração profunda, você pode temporariamente definir LogLevel DEBUG em /etc/ssh/sshd_config e reiniciar o sshd. Lembre-se de reverter esta configuração após a solução de problemas, pois logs de depuração podem ser muito detalhados e consumir espaço em disco.

Conclusão

Use ssh -vvv para ver o que seu cliente oferece, depois verifique os logs do servidor para saber por que o sshd rejeitou. A maioria das falhas de chave pública se resume à chave errada, uma entrada authorized_keys ausente, permissões estritas de arquivo ou uma regra sshd_config que bloqueia o usuário ou método.