Solução de Problemas SSH

Nota: Este é o último tutorial da série sobre SSH. Se você perdeu o anterior sobre hardening de segurança adicional, pode encontrá-lo aqui: Hardening de Segurança Adicional para SSH.

Mesmo com o conhecimento adquirido ao longo desta série, você inevitavelmente encontrará problemas com conexões SSH em algum momento. Pode ser uma configuração incorreta, permissões inadequadas, problemas de rede, ou simplesmente um erro de digitação. Saber como diagnosticar e resolver esses problemas é uma habilidade essencial para qualquer administrador de sistemas ou usuário avançado.

Neste tutorial final, exploraremos as ferramentas e técnicas para identificar e solucionar os problemas mais comuns relacionados ao SSH.

1. Modo Verboso do Cliente SSH

A primeira e mais importante ferramenta de diagnóstico é o modo verboso do cliente SSH. Ele fornece informações detalhadas sobre o processo de conexão, incluindo a negociação de chaves, autenticação e erros encontrados.

Níveis de Verbosidade:

• -v: Verbosidade básica. Mostra informações sobre a negociação de chaves, autenticação e erros.
• -vv: Verbosidade média. Inclui mais detalhes sobre o processo de conexão.
• -vvv: Verbosidade máxima. Mostra informações extremamente detalhadas, útil para problemas complexos.

Como Usar:

ssh -v usuario@host
ssh -vv usuario@host
ssh -vvv usuario@host

Dica Crucial: Ao analisar a saída verbosa, foque nas últimas linhas antes do erro. A saída pode ser extensa, mas geralmente as linhas finais contêm a informação mais relevante sobre o que deu errado.

Exemplo de Saída Verbosa e Interpretação:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:AbCdEf... explicit agent
debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519 SHA256:AbCdEf... explicit agent
debug1: Authentication succeeded (publickey).
Authenticated to example.com ([192.168.1.100]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/remoteuser/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/remoteuser/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding

Esta saída indica uma conexão bem-sucedida usando autenticação por chave pública. O cliente ofereceu a chave /home/user/.ssh/id_ed25519, o servidor a aceitou, e a autenticação foi bem-sucedida.

Exemplo de Erro e Interpretação:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:AbCdEf... explicit agent
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
user@example.com's password:

Neste caso, o servidor rejeitou a chave pública oferecida (não vemos “Server accepts key”) e passou para o próximo método de autenticação (senha). Isso pode indicar que a chave pública não está corretamente instalada no arquivo authorized_keys do servidor, ou há problemas de permissão.

2. Análise de Logs do Servidor SSHd

Quando o modo verboso do cliente não é suficiente, os logs do servidor SSH podem fornecer informações adicionais valiosas, especialmente para problemas de autenticação ou configuração do servidor.

Localização dos Logs:

A localização dos logs do SSH varia dependendo da distribuição Linux:

• Debian/Ubuntu: /var/log/auth.log
• RHEL/CentOS/Fedora: /var/log/secure
• Sistemas com systemd: journalctl -u sshd

Aumentando o Nível de Detalhamento:

Para obter logs mais detalhados, você pode temporariamente aumentar o nível de log no servidor:

1. Edite /etc/ssh/sshd_config:

   # Adicione ou modifique esta linha:
   LogLevel DEBUG  # Ou DEBUG1, DEBUG2, DEBUG3 para níveis crescentes de detalhe
   

2. Reinicie ou recarregue o serviço SSH:

   sudo systemctl restart sshd
   # ou
   sudo service ssh restart
   

3. Reproduza o problema (tente conectar novamente).
4. Verifique os logs.
5. Importante: Volte o LogLevel para o valor padrão (INFO) após a solução do problema, pois logs muito detalhados podem crescer rapidamente e consumir espaço em disco.

Exemplo de Entradas de Log e Interpretação:

Autenticação bem-sucedida:

Jun 12 14:30:45 server sshd[12345]: Accepted publickey for user from 192.168.1.10 port 54321 ssh2: ED25519 SHA256:AbCdEf...
Jun 12 14:30:45 server sshd[12345]: pam_unix(sshd:session): session opened for user user by (uid=0)

Falha de autenticação por chave:

Jun 12 14:32:10 server sshd[12346]: Authentication refused: bad ownership or modes for directory /home/user/.ssh

Este erro indica um problema de permissões no diretório .ssh.

Tentativa de login com usuário inexistente:

Jun 12 14:33:22 server sshd[12347]: Invalid user nonexistent from 192.168.1.10 port 54322

Problema de permissão em arquivo de chave de host:

Jun 12 14:34:15 server sshd[12348]: Could not load host key: /etc/ssh/ssh_host_ed25519_key

3. Problemas Comuns e Soluções

3.1. Erros de Permissão

O SSH é extremamente rigoroso quanto às permissões de arquivos e diretórios, especialmente aqueles relacionados às chaves.

Problema: Mensagens como “Authentication refused: bad ownership or modes” ou “Permission denied (publickey)”.

Solução:

• No cliente:

  chmod 700 ~/.ssh
  chmod 600 ~/.ssh/id_ed25519  # Ou qualquer chave privada
  chmod 644 ~/.ssh/id_ed25519.pub  # Chave pública
  

• No servidor:

  chmod 700 ~/.ssh
  chmod 600 ~/.ssh/authorized_keys
  

• Verificar propriedade: Certifique-se de que os arquivos e diretórios pertencem ao usuário correto:

  chown -R seu_usuario:seu_grupo ~/.ssh
  

3.2. Timeouts

Problema: A conexão parece congelar e eventualmente falha com “Connection timed out”.

Possíveis Causas e Soluções:

• Problemas de rede:
  • Verifique se o servidor está acessível: ping hostname_ou_ip
  • Verifique se a porta SSH está aberta: telnet hostname_ou_ip 22 (ou a porta configurada)
  • Use traceroute para identificar onde a conexão está sendo interrompida
• Firewall bloqueando:
  • Verifique regras de firewall no cliente: sudo iptables -L
  • Verifique regras de firewall no servidor
  • Verifique firewalls de rede intermediários
• Configuração de ClientAliveInterval:
  • Se a conexão cai após um período de inatividade, ajuste no servidor:

      # Em /etc/ssh/sshd_config
      ClientAliveInterval 60  # Envia um pacote a cada 60 segundos
      ClientAliveCountMax 3   # Tolera 3 falhas antes de desconectar
    

  • Ou no cliente:

      # Em ~/.ssh/config
      Host *
      ServerAliveInterval 60
      ServerAliveCountMax 3
    

3.3. Portas Bloqueadas

Problema: “Connection refused” ao tentar conectar.

Possíveis Causas e Soluções:

• Serviço SSH não está rodando:

  # No servidor:
  sudo systemctl status sshd  # ou service ssh status
  # Se parado:
  sudo systemctl start sshd   # ou service ssh start
  

• SSH escutando em porta diferente:
  • Verifique a configuração Port em /etc/ssh/sshd_config
  • Use a flag -p ao conectar: ssh -p 2222 usuario@host
• Firewall bloqueando a porta:

  # No servidor (exemplo para UFW):
  sudo ufw status
  sudo ufw allow 22/tcp  # Ou a porta configurada
      
  # No servidor (exemplo para iptables):
  sudo iptables -L
  sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
  sudo iptables-save
  

3.4. Incompatibilidade de Chaves/Algoritmos

Problema: Erros como “no matching key exchange method found” ou “no matching cipher found”.

Solução:

• Identificar algoritmos suportados pelo servidor:

  ssh -Q cipher  # Lista cifras suportadas pelo cliente
  ssh -Q kex     # Lista algoritmos de troca de chaves
  ssh -Q mac     # Lista algoritmos MAC
  

• Especificar algoritmos explicitamente para teste:

  ssh -o KexAlgorithms=diffie-hellman-group14-sha1 -o Ciphers=aes128-ctr usuario@host
  

• Atualizar o OpenSSH (cliente ou servidor) se possível, pois versões mais recentes têm melhor compatibilidade.

• Ajustar configurações permanentemente:
  • No cliente (~/.ssh/config):

      Host problema.exemplo.com
      KexAlgorithms +diffie-hellman-group14-sha1
      Ciphers +aes128-ctr
    

  • No servidor (/etc/ssh/sshd_config), se você controla ambos os lados:

      KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group14-sha1
      Ciphers chacha20-poly1305@openssh.com,aes128-ctr
    

3.5. Erros de Known_Hosts

Problema: “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!” ou “Someone could be eavesdropping on you right now (man-in-the-middle attack)!”

Causas e Soluções:

• Mudança legítima no servidor (reinstalação do SO, regeneração de chaves):
  • Se você tem certeza de que a mudança é legítima, remova a entrada antiga:

      ssh-keygen -R hostname_ou_ip
    

  • Ou edite manualmente ~/.ssh/known_hosts e remova a linha correspondente.
• Possível ataque Man-in-the-Middle:
  • Se você não esperava uma mudança, investigue! Contate o administrador do servidor para verificar se houve uma mudança legítima.
  • Verifique se está conectando ao host correto (DNS, IP).

3.6. Connection Refused

Problema: “Connection refused” ao tentar conectar.

Possíveis Causas e Soluções:

• Serviço SSH não está rodando:
  • Inicie o serviço como mostrado anteriormente.
• Servidor escutando apenas em interfaces específicas:
  • Verifique a diretiva ListenAddress em /etc/ssh/sshd_config.
  • Certifique-se de que o servidor está escutando na interface pela qual você está tentando acessar.
• Problemas de resolução de nome:
  • Tente conectar usando o endereço IP em vez do nome de host.

3.7. Permission Denied

Problema: “Permission denied” após tentar autenticar.

Possíveis Causas e Soluções:

• Senha incorreta:
  • Verifique se o Caps Lock está desativado.
  • Certifique-se de que está usando a senha correta.
• Chave pública não aceita:
  • Verifique se a chave pública está corretamente adicionada ao ~/.ssh/authorized_keys no servidor.
  • Verifique permissões como mencionado anteriormente.
• Usuário não permitido:
  • Verifique as diretivas AllowUsers, DenyUsers, AllowGroups, DenyGroups em /etc/ssh/sshd_config.
  • Verifique se o usuário existe no servidor: getent passwd nome_usuario.
• Método de autenticação não permitido:
  • Verifique se o método que você está tentando usar (senha, chave) está habilitado no servidor.
  • Para autenticação por senha: PasswordAuthentication yes em sshd_config.
  • Para autenticação por chave: PubkeyAuthentication yes em sshd_config.

4. Fluxograma de Diagnóstico

Aqui está um fluxograma simplificado para ajudar a diagnosticar problemas de SSH:

1. Tente conectar com verbosidade máxima: ssh -vvv usuario@host
2. Analise a saída:
   • Se “Connection refused”: Verifique se o serviço está rodando e escutando na porta correta.
   • Se “Connection timed out”: Verifique problemas de rede, firewall.
   • Se “Permission denied”: Verifique autenticação (senha/chave), permissões de arquivos.
   • Se “Host key verification failed”: Resolva problemas de known_hosts.
3. Verifique logs do servidor: /var/log/auth.log ou equivalente.
4. Teste com configurações mínimas:
   • Tente desabilitar temporariamente configurações personalizadas: ssh -F /dev/null usuario@host
5. Verifique permissões de arquivos e diretórios.
6. Teste conectividade básica: ping, telnet, traceroute.

Conclusão

A solução de problemas SSH é uma habilidade que se desenvolve com a prática. As ferramentas e técnicas apresentadas neste tutorial devem ajudá-lo a diagnosticar e resolver a maioria dos problemas comuns. Lembre-se de que o modo verboso do cliente (-v, -vv, -vvv) e os logs do servidor são seus melhores aliados nesse processo.

Quando enfrentar um problema, aborde-o metodicamente:

1. Identifique os sintomas exatos.
2. Colete informações usando as ferramentas de diagnóstico.
3. Formule hipóteses sobre a causa.
4. Teste cada hipótese.
5. Aplique a solução e verifique se resolveu o problema.

Com isso, concluímos nossa série abrangente sobre SSH. Esperamos que estes tutoriais tenham fornecido uma base sólida para você usar o SSH com confiança, segurança e eficiência em seus ambientes de trabalho e pessoais.

Obrigado por acompanhar esta jornada!