Troubleshooting de Conexao SSH - Corrigir Permission Denied e Problemas de Chave

2025-12-15 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediario

O que voce vai aprender

• Como resolver sistematicamente problemas de conexao SSH
• Como corrigir Permission denied (publickey) e Host key verification failed
• Evitar armadilhas comuns com arquivos de chave, permissoes, known_hosts e configuracao do sshd

1. Comandos basicos de conexao

Conclusao: Conheca as tres 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)

Conclusao: Sempre execute ssh -v primeiro -- ele nomeia o metodo de autenticacao que falhou e a etapa.

A saida detalhada e a forma mais rapida de identificar o problema.

$ ssh -v user@server.example.com

Ainda mais detalhes (quando necessario):

$ ssh -vv user@server.example.com

Caso A: Permission denied (publickey)

Conclusao: Confirme que a chave existe, ~/.ssh 700, chave 600, chave publica em authorized_keys.

Significado: O servidor e alcancavel mas a autenticacao por chave foi rejeitada

Verificacao 1: O arquivo da chave existe?

$ ls -la ~/.ssh

Verificacao 2: Permissoes do arquivo da chave (permissoes erradas = chave nao funciona)

Permissoes recomendadas:

• Chave privada: 600
• Diretorio .ssh: 700

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

Verificacao 3: Especifique explicitamente qual chave

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

Verificacao 4: Chave publica registrada no servidor?

No servidor (via console ou acesso alternativo):

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

Corrigir permissoes:

$ 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

Conclusao: 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 apos reconstrucoes de servidor ou reuso de IP.

Correcao (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 impressao digital antes de aceitar.

Caso C: Connection timed out

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

Significado: Rede inalcancavel (firewall/grupo de seguranca/roteamento/porta errada)

Verificacao 1: DNS resolvendo?

$ dig server.example.com +short

Verificacao 2: Porta aberta?

Usando nc:

$ nc -vz server.example.com 22

Porta diferente:

$ nc -vz server.example.com 2222

Caso D: Connection refused

Conclusao: Connection refused significa que o sshd nao esta escutando -- verifique systemctl status ssh.

Significado: O servidor e alcancavel mas o SSH nao esta escutando naquela porta

Verificacao 1: Servico sshd rodando?

No Ubuntu, o servico geralmente se chama ssh:

$ sudo systemctl status ssh

Iniciar:

$ sudo systemctl start ssh

Habilitar auto-inicio:

$ sudo systemctl enable ssh

Verificacao 2: Verificar porta em escuta

$ sudo ss -lntp | grep ssh

4. Investigacao de logs no servidor (journalctl)

Conclusao: Execute journalctl -u ssh -n 200 -- os logs revelam a falha de autenticacao 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/usuario errado) frequentemente aparece nos logs.