Corrigindo "Permission denied (publickey)" - Verificando a Autenticação por Chave Pública SSH

2026-06-05 Tempo de leitura: Cerca de 11 min Dificuldade: Intermediário

O que significa "Permission denied (publickey)"?

Conclusão: Você alcançou o servidor, mas a autenticação por chave pública foi rejeitada. Não é um problema de rede ou senha -- apenas a chave falhou na autenticação.

Esse erro significa que a conexão TCP foi bem-sucedida e seu cliente está se comunicando com o sshd do servidor. Isso é uma etapa diferente de Connection timed out ou Connection refused. O servidor está dizendo: "Tentei a autenticação publickey, mas não consegui verificar uma chave válida."

user@server: Permission denied (publickey).

A palavra entre parênteses é a lista de métodos de autenticação que o servidor está permitindo no momento. (publickey,password) significa que tanto chave quanto senha funcionam, mas (publickey) sozinho significa que a autenticação por senha está desabilitada -- seu único caminho é uma chave funcional.

O que verificar primeiro?

Conclusão: Execute ssh -v para ver se uma chave está sendo oferecida e em qual etapa o servidor a rejeita. Isso sozinho divide a causa em lado do cliente vs lado do servidor.

A causa é, de forma geral, uma de duas: o cliente não está oferecendo a chave correta, ou o servidor não está aceitando a chave oferecida. Separar essas duas possibilidades primeiro é o passo decisivo, e a saída do -v fornece a evidência.

$ ssh -v user@server.example.com

Linhas para observar:

debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

Se Offering public key nunca aparece -> o cliente não está oferecendo uma chave (problema no lado do cliente). Se Offering public key aparece mas ainda é rejeitada -> o servidor não está aceitando a chave (problema no lado do servidor).

Por que a chave é rejeitada? Visão geral

Conclusão: As causas se dividem em três camadas -- cliente, servidor e configuração do sshd. Trabalhar de cima para baixo evita que você se perca.

O restante deste artigo percorre essas três camadas em ordem.

Como ler a saída do ssh -v?

Conclusão: -v imprime cada chave tentada e os métodos de autenticação que o servidor diz que podem continuar. A habilidade principal é identificar onde a conversa para.

Aqui estão os padrões típicos.

Nenhuma chave oferecida:

debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

Não há linha Offering public key. O cliente não conseguiu encontrar uma chave para usar.

Chave oferecida mas rejeitada:

debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
debug1: Authentications that can continue: publickey

Uma chave foi oferecida mas o servidor não a aceitou. Suspeite do authorized_keys ou das permissões do servidor.

Lado do cliente: você está oferecendo a chave correta?

Conclusão: Verifique a existência da chave privada, suas permissões e como ela é especificada. Se -i funcionar, o problema está na sua configuração ou agent.

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

$ ls -la ~/.ssh

Confirme que você tem o par: id_ed25519 (privada) e id_ed25519.pub (pública).

Verificação 2: Permissões da chave privada

Se as permissões da chave privada estiverem muito abertas, o ssh se recusa a usá-la por segurança e exibe o aviso Permissions 0644 for ... are too open.

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

Verificação 3: Especifique a chave explicitamente

Com múltiplas chaves ou sem ~/.ssh/config, a chave pretendida pode não ser oferecida.

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

Se isso funcionar, a chave em si está correta. Torne permanente em ~/.ssh/config.

Host server
    HostName server.example.com
    User user
    IdentityFile ~/.ssh/id_ed25519

Verificação 4: O nome de usuário está correto?

O que importa é em qual authorized_keys sua chave pública está registrada. Uma chave correta com o usuário de login errado ainda é rejeitada.

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

Lado do servidor: verificando authorized_keys e permissões

Conclusão: Verifique se a chave pública está em authorized_keys, e se o dono e as permissões de .ssh e authorized_keys estão corretos. Permissões frouxas fazem o StrictModes ignorar a chave.

Se você consegue acessar o servidor por outro caminho (console ou uma sessão existente), inspecione o ~/.ssh do usuário alvo.

Verificação 1: A chave pública está registrada?

$ cat ~/.ssh/authorized_keys

Procure uma linha correspondente ao id_ed25519.pub do seu cliente. Se estiver ausente, adicione-a. Para instalar em um único passo a partir do cliente:

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

Ou adicione a chave pública manualmente:

$ cat ~/.ssh/id_ed25519.pub | ssh user@server 'cat >> ~/.ssh/authorized_keys'

Verificação 2: Propriedade e permissões (StrictModes)

O sshd usa StrictModes yes por padrão, então se as permissões do home ou .ssh estiverem frouxas, ou o proprietário estiver errado, ele rejeita a autenticação mesmo com uma chave correta. Essa é uma armadilha muito comum.

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

Note que um diretório home gravável por grupo/outros também é rejeitado.

$ chmod go-w ~

Como confirmar o motivo nos logs do servidor?

Conclusão: journalctl -u ssh mostra o log de autenticação do servidor com o motivo específico da rejeição -- chave incompatível, permissões ou usuário errado. Isso elimina as suposições.

$ sudo journalctl -u ssh -n 100 --no-pager

Acompanhar em tempo real:

$ sudo journalctl -u ssh -f

Em algumas distribuições o log fica em /var/log/auth.log.

$ sudo tail -f /var/log/auth.log

Linhas típicas:

• Authentication refused: bad ownership or modes for directory -> permissões/propriedade
• error: Could not open authorized keys -> problema de caminho ou existência
• Invalid user xxx -> nome de usuário errado

Quando suspeitar do sshd_config?

Conclusão: A autenticação por chave pública pode estar desabilitada, ou o caminho do arquivo de chaves pode ser diferente do padrão. Use sshd -T para ver os valores efetivos.

A configuração efetiva do servidor é melhor lida com sshd -T em vez do arquivo bruto (ele imprime o resultado mesclado dos blocos Match e arquivos incluídos).

$ sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile'

Pontos a confirmar:

• pubkeyauthentication yes (se no, a autenticação por chave está desabilitada)
• authorizedkeysfile .ssh/authorized_keys está conforme esperado (não alterado para um caminho personalizado)

Após alterar a configuração, aplique-a.

$ sudo systemctl reload ssh

A chave está carregada no ssh-agent?

Conclusão: Ao autenticar via agent, uma chave não carregada nunca é oferecida. Use ssh-add -l para listar as chaves carregadas.

Quando você não está usando IdentitiesOnly, ou passando por um bastion (ProxyJump), as chaves carregadas no agent são usadas.

$ ssh-add -l

The agent has no identities. significa que nenhuma chave está carregada. Adicione uma.

$ ssh-add ~/.ssh/id_ed25519

Se você usa encaminhamento de agent (-A), ele assume que a chave está presente no seu agent local.

Checklist quando ainda falha

Conclusão: Vá de cliente -> servidor -> config sshd -> logs, verificando oferecimento, registro, permissões e configurações efetivas um por um. A maioria dos casos converge para permissões ou um usuário errado.

• [ ] O ssh -v mostra Offering public key?
• [ ] A chave privada está com 600 e ~/.ssh com 700?
• [ ] Especificar a chave com -i funciona?
• [ ] O nome de usuário de login está correto?
• [ ] A chave pública está no authorized_keys do servidor?
• [ ] O proprietário e as permissões de ~, ~/.ssh e authorized_keys estão corretos (StrictModes)?
• [ ] O sshd -T mostra pubkeyauthentication yes?
• [ ] O journalctl -u ssh mostra um motivo de rejeição?
• [ ] Ao usar agent, a chave está em ssh-add -l?