Troubleshooting de Conexão SSH - Corrigir Permission Denied e Problemas de Chave

2025-12-15 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediário

O que você vai aprender

• Como resolver sistematicamente problemas de conexão SSH
• Como corrigir Permission denied (publickey) e Host key verification failed
• Evitar armadilhas comuns com arquivos de chave, permissões, known_hosts e configuração do sshd

1. Comandos básicos de conexão

Conclusão: Conheça as três formas do ssh -- simples, -p para porta, -i para arquivo de chave.

$ ssh user@server.example.com

Especificando uma porta (ex.: 2222):

$ ssh -p 2222 user@server.example.com

Especificando um arquivo de chave:

$ ssh -i ~/.ssh/id_ed25519 user@server.example.com

2. Depurar com a flag -v (comece aqui)

Conclusão: Sempre execute ssh -v primeiro -- ele nomeia o método de autenticação que falhou e a etapa.

A saída detalhada é a forma mais rápida de identificar o problema.

$ ssh -v user@server.example.com

Ainda mais detalhes (quando necessário):

$ ssh -vv user@server.example.com

Caso A: Permission denied (publickey)

Conclusão: Confirme que a chave existe, ~/.ssh 700, chave 600, chave pública em authorized_keys.

Significado: O servidor é alcançável mas a autenticação por chave foi rejeitada

Verificação 1: O arquivo da chave existe?

$ ls -la ~/.ssh

Verificação 2: Permissões do arquivo da chave (permissões erradas = chave não funciona)

Permissões recomendadas:

• Chave privada: 600
• Diretório .ssh: 700

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ed25519

Verificação 3: Especifique explicitamente qual chave

$ ssh -i ~/.ssh/id_ed25519 user@server.example.com

Verificação 4: Chave pública registrada no servidor?

No servidor (via console ou acesso alternativo):

$ ls -la /home/user/.ssh
$ ls -la /home/user/.ssh/authorized_keys

Corrigir permissões:

$ chmod 700 /home/user/.ssh
$ chmod 600 /home/user/.ssh/authorized_keys
$ chown -R user:user /home/user/.ssh

Caso B: Host key verification failed

Conclusão: Execute ssh-keygen -R <host> para remover a chave obsoleta, depois reconecte e verifique.

Significado: O SSH esta verificando "Este e realmente o mesmo servidor ao qual me conectei antes?" Comum após reconstruções de servidor ou reuso de IP.

Correção (remover a entrada do host de known_hosts):

$ ssh-keygen -R server.example.com

Se conectando por IP:

$ ssh-keygen -R 203.0.113.10

Depois reconecte e verifique a impressão digital antes de aceitar.

Caso C: Connection timed out

Conclusão: Um timeout significa que nenhum pacote chegou -- use dig e nc -vz para encontrar o bloqueio.

Significado: Rede inalcançável (firewall/grupo de segurança/roteamento/porta errada)

Verificação 1: DNS resolvendo?

$ dig server.example.com +short

Verificação 2: Porta aberta?

Usando nc:

$ nc -vz server.example.com 22

Porta diferente:

$ nc -vz server.example.com 2222

Caso D: Connection refused

Conclusão: Connection refused significa que o sshd não está escutando -- verifique systemctl status ssh.

Significado: O servidor é alcançável mas o SSH não está escutando naquela porta

Verificação 1: Serviço sshd rodando?

No Ubuntu, o serviço geralmente se chama ssh:

$ sudo systemctl status ssh

Iniciar:

$ sudo systemctl start ssh

Habilitar auto-início:

$ sudo systemctl enable ssh

Verificação 2: Verificar porta em escuta

$ sudo ss -lntp | grep ssh

4. Investigação de logs no servidor (journalctl)

Conclusão: Execute journalctl -u ssh -n 200 -- os logs revelam a falha de autenticação exata.

Os logs do servidor podem identificar o problema de forma definitiva:

$ sudo journalctl -u ssh -n 200

Acompanhar logs em tempo real:

$ sudo journalctl -u ssh -f

O motivo do Permission denied (chave errada/usuário errado) frequentemente aparece nos logs.