Diagnóstico e Resolução de Falhas de Autenticação SSH

O Secure Shell (SSH) é a base da administração remota segura, permitindo o 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 surgir de uma infinidade de causas, que vão desde simples erros de digitação até complexos problemas de permissão ou configurações incorretas.

Este artigo serve como um guia abrangente para diagnosticar e resolver eficazmente falhas de autenticação SSH. Exploraremos 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á equipado para identificar a causa raiz da maioria dos problemas de autenticação e restaurar seu acesso remoto seguro.

Compreendendo 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 emprega:

• 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 analisar logs detalhados, é prudente realizar algumas verificações básicas, pois muitos problemas são frequentemente omissões simples:

• Nome de Usuário e Hostname Corretos: Verifique 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 ping para verificar a conectividade básica de rede.
  bash 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.
  bash sudo systemctl status sshd # Para sistemas baseados em systemd (a maioria dos Linux modernos) sudo service sshd status # Para sistemas init mais antigos
• Porta SSH: O daemon SSH está escutando 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.
  bash 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 as tentativas de autenticação. Esta saída é inestimável para entender por que o cliente acredita 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).

Exemplo de Comando:

ssh -vvv username@your_server_ip

Interpretando a Saída Detalhada

Ao executar ssh em modo detalhado, procure por linhas-chave que indiquem 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-o.
  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 por chave pública bem-sucedida do ponto de vista 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 logo 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 do servidor a todas as tentativas.

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 os Logs do Servidor SSH

Embora a saída detalhada do lado do cliente mostre 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 da causa raiz.

Localizando os 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 (a 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 por entradas específicas do SSH.

Exemplos de Comandos:

# 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 anteriormente)
sudo journalctl -u sshd

Entradas Comuns de Log do Servidor e Seus Significados

Procure por mensagens relacionadas a sshd quando você tenta se conectar. Aqui estão algumas entradas comuns indicando 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 por 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 quanto às permissões por motivos 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 acesso SSH explicitamente negado por DenyUsers.
• input_userauth_request: invalid user username: O nome de usuário fornecido não existe no servidor.
• Publickey authentication refused: authenticate using identity file.: Isso geralmente significa que a chave pública apresentada pelo cliente não corresponde a nenhuma chave no arquivo authorized_keys do servidor para esse usuário, ou o formato da chave está incorreto.
• 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. Esteja ciente de layouts de teclado, Caps Lock ou Num Lock.
• Usuário Não Permissível: O arquivo sshd_config (/etc/ssh/sshd_config) pode restringir o login para certos usuários.
  • PermitRootLogin no: Impede o login root (altamente recomendado por segurança).
  • AllowUsers username1 username2: Apenas usuários especificados podem fazer login.
  • DenyUsers username: Usuários especificados não podem fazer login.
  • AllowGroups groupname: Apenas usuários em grupos especificados podem fazer login.
  • Solução: Ajuste as diretivas sshd_config e reinicie o sshd.
• Problemas de PAM: Se o servidor usar Módulos de Autenticação Pluggáveis (PAM), problemas na 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 é frequentemente 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 requer permissões rigorosas 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).
    bash chmod 700 ~/.ssh
  • ~/.ssh/authorized_keys: Deve ser 600 (rw apenas para o proprietário).
    bash chmod 600 ~/.ssh/authorized_keys
  • O proprietário desses arquivos e diretórios deve ser o usuário que está tentando fazer login.
    bash sudo chown -R username:username ~/.ssh
• Conteúdo Incorreto de authorized_keys: A chave pública em ~/.ssh/authorized_keys pode estar corrompida, ter caracteres extras ou estar em formato incorreto. Cada chave deve estar em uma única linha. Uma maneira rápida de garantir o formato correto é usar ssh-copy-id do cliente.
  bash ssh-copy-id -i ~/.ssh/id_rsa.pub username@your_server_ip
  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 estar 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:
    bash ssh -i /path/to/your/private_key username@your_server_ip
  • Se estiver usando ssh-agent, certifique-se de que sua chave foi adicionada:
    bash eval "$(ssh-agent -s)" ssh-add ~/.ssh/your_private_key
• sshd_config Desautorizando Autenticação por Chave Pública: O daemon SSH do servidor pode estar configurado para desautorizar a autenticação por chave pública.
  • Verifique PubkeyAuthentication yes em /etc/ssh/sshd_config.
  • Verifique AuthorizedKeysFile .ssh/authorized_keys para garantir que ele aponte para o arquivo correto. O padrão geralmente é suficiente.
  • Solução: Defina PubkeyAuthentication yes e reinicie o sshd.
• Interferência SELinux/AppArmor: Em sistemas com SELinux ou AppArmor, esses módulos de segurança podem às vezes impedir o SSH de acessar diretórios home de usuários ou arquivos .ssh, mesmo que as permissões de arquivo estejam corretas. Verifique os logs de auditoria (/var/log/audit/audit.log ou sudo ausearch -m AVC -ts recent) em busca de pistas. Este é um cenário avançado.

3. Conexão Recusada ou Tempo Esgotado

Embora não sejam estritamente falhas de "autenticação", estas geralmente precedem as tentativas de autenticação e as impedem de sequer começar.

• Bloqueio de Firewall: Verifique firewalls tanto no cliente (por exemplo, firewall local do SO) quanto no servidor (por exemplo, ufw, firewalld, grupos de segurança de nuvem, ACLs de rede). Certifique-se de que a porta 22 (ou porta personalizada) esteja aberta.
• Servidor SSH Não em Execução: O serviço sshd pode não estar ativo ou pode ter travado.
• Porta/IP Incorreto: Tentando se conectar à 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 quaisquer 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 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 nova configuração. Se funcionar, o problema é específico da configuração do usuário original.
• Isole o Problema: Tente se conectar 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 LogLevel (Lado do Servidor): Para depuração profunda, você pode definir temporariamente LogLevel DEBUG em /etc/ssh/sshd_config e reiniciar o sshd. Lembre-se de reverter essa configuração após a solução de problemas, pois os logs de depuração podem ser muito detalhados e consumir espaço em disco.

Conclusão

Diagnosticar falhas de autenticação SSH requer uma abordagem sistemática, combinando saída detalhada do lado do cliente com análise de logs do lado do servidor. Ao examinar meticulosamente as pistas fornecidas por ssh -vvv e os logs do daemon SSH (auth.log ou secure), você pode identificar efetivamente o ponto exato da falha, seja uma senha incorreta, uma chave pública mal configurada, permissões de arquivo rigorosas ou uma configuração do lado do servidor.

Lembre-se de começar com as verificações simples, depois passar para a saída detalhada do lado do cliente e, finalmente, alavancar as informações definitivas dos logs do servidor. Com essas técnicas, você estará bem equipado para resolver até mesmo os problemas de autenticação SSH mais complexos e manter o acesso seguro aos seus sistemas remotos.