Corrigindo "Permission denied (publickey)" - Verificando a Autenticacao por Chave Publica SSH

2026-06-05 Tempo de leitura: Cerca de 11 min Dificuldade: Intermediario

O que significa "Permission denied (publickey)"?

Conclusao: Voce alcancou o servidor, mas a autenticacao por chave publica foi rejeitada. Nao e um problema de rede ou senha -- apenas a chave falhou na autenticacao.

Esse erro significa que a conexao TCP foi bem-sucedida e seu cliente esta se comunicando com o sshd do servidor. Isso e uma etapa diferente de Connection timed out ou Connection refused. O servidor esta dizendo: "Tentei a autenticacao publickey, mas nao consegui verificar uma chave valida."

user@server: Permission denied (publickey).

A palavra entre parenteses e a lista de metodos de autenticacao que o servidor esta permitindo no momento. (publickey,password) significa que tanto chave quanto senha funcionam, mas (publickey) sozinho significa que a autenticacao por senha esta desabilitada -- seu unico caminho e uma chave funcional.

O que verificar primeiro?

Conclusao: Execute ssh -v para ver se uma chave esta 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 e, de forma geral, uma de duas: o cliente nao esta oferecendo a chave correta, ou o servidor nao esta aceitando a chave oferecida. Separar essas duas possibilidades primeiro e o passo decisivo, e a saida do -v fornece a evidencia.

$ 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 nao esta oferecendo uma chave (problema no lado do cliente). Se Offering public key aparece mas ainda e rejeitada -> o servidor nao esta aceitando a chave (problema no lado do servidor).

Por que a chave e rejeitada? Visao geral

Conclusao: As causas se dividem em tres camadas -- cliente, servidor e configuracao do sshd. Trabalhar de cima para baixo evita que voce se perca.

O restante deste artigo percorre essas tres camadas em ordem.

Como ler a saida do ssh -v?

Conclusao: -v imprime cada chave tentada e os metodos de autenticacao que o servidor diz que podem continuar. A habilidade principal e identificar onde a conversa para.

Aqui estao os padroes tipicos.

Nenhuma chave oferecida:

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

Nao ha linha Offering public key. O cliente nao 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 nao a aceitou. Suspeite do authorized_keys ou das permissoes do servidor.

Lado do cliente: voce esta oferecendo a chave correta?

Conclusao: Verifique a existencia da chave privada, suas permissoes e como ela e especificada. Se -i funcionar, o problema esta na sua configuracao ou agent.

Verificacao 1: O arquivo da chave existe?

$ ls -la ~/.ssh

Confirme que voce tem o par: id_ed25519 (privada) e id_ed25519.pub (publica).

Verificacao 2: Permissoes da chave privada

Se as permissoes da chave privada estiverem muito abertas, o ssh se recusa a usa-la por seguranca e exibe o aviso Permissions 0644 for ... are too open.

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

Verificacao 3: Especifique a chave explicitamente

Com multiplas chaves ou sem ~/.ssh/config, a chave pretendida pode nao ser oferecida.

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

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

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

Verificacao 4: O nome de usuario esta correto?

O que importa e em qual authorized_keys sua chave publica esta registrada. Uma chave correta com o usuario de login errado ainda e rejeitada.

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

Lado do servidor: verificando authorized_keys e permissoes

Conclusao: Verifique se a chave publica esta em authorized_keys, e se o dono e as permissoes de .ssh e authorized_keys estao corretos. Permissoes frouxas fazem o StrictModes ignorar a chave.

Se voce consegue acessar o servidor por outro caminho (console ou uma sessao existente), inspecione o ~/.ssh do usuario alvo.

Verificacao 1: A chave publica esta 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 unico passo a partir do cliente:

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

Ou adicione a chave publica manualmente:

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

Verificacao 2: Propriedade e permissoes (StrictModes)

O sshd usa StrictModes yes por padrao, entao se as permissoes do home ou .ssh estiverem frouxas, ou o proprietario estiver errado, ele rejeita a autenticacao mesmo com uma chave correta. Essa e uma armadilha muito comum.

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

Note que um diretorio home gravavel por grupo/outros tambem e rejeitado.

$ chmod go-w ~

Como confirmar o motivo nos logs do servidor?

Conclusao: journalctl -u ssh mostra o log de autenticacao do servidor com o motivo especifico da rejeicao -- chave incompativel, permissoes ou usuario errado. Isso elimina as suposicoes.

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

Acompanhar em tempo real:

$ sudo journalctl -u ssh -f

Em algumas distribuicoes o log fica em /var/log/auth.log.

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

Linhas tipicas:

• Authentication refused: bad ownership or modes for directory -> permissoes/propriedade
• error: Could not open authorized keys -> problema de caminho ou existencia
• Invalid user xxx -> nome de usuario errado

Quando suspeitar do sshd_config?

Conclusao: A autenticacao por chave publica pode estar desabilitada, ou o caminho do arquivo de chaves pode ser diferente do padrao. Use sshd -T para ver os valores efetivos.

A configuracao efetiva do servidor e melhor lida com sshd -T em vez do arquivo bruto (ele imprime o resultado mesclado dos blocos Match e arquivos incluidos).

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

Pontos a confirmar:

• pubkeyauthentication yes (se no, a autenticacao por chave esta desabilitada)
• authorizedkeysfile .ssh/authorized_keys esta conforme esperado (nao alterado para um caminho personalizado)

Apos alterar a configuracao, aplique-a.

$ sudo systemctl reload ssh

A chave esta carregada no ssh-agent?

Conclusao: Ao autenticar via agent, uma chave nao carregada nunca e oferecida. Use ssh-add -l para listar as chaves carregadas.

Quando voce nao esta usando IdentitiesOnly, ou passando por um bastion (ProxyJump), as chaves carregadas no agent sao usadas.

$ ssh-add -l

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

$ ssh-add ~/.ssh/id_ed25519

Se voce usa encaminhamento de agent (-A), ele assume que a chave esta presente no seu agent local.

Checklist quando ainda falha

Conclusao: Va de cliente -> servidor -> config sshd -> logs, verificando oferecimento, registro, permissoes e configuracoes efetivas um por um. A maioria dos casos converge para permissoes ou um usuario errado.

• [ ] O ssh -v mostra Offering public key?
• [ ] A chave privada esta com 600 e ~/.ssh com 700?
• [ ] Especificar a chave com -i funciona?
• [ ] O nome de usuario de login esta correto?
• [ ] A chave publica esta no authorized_keys do servidor?
• [ ] O proprietario e as permissoes de ~, ~/.ssh e authorized_keys estao corretos (StrictModes)?
• [ ] O sshd -T mostra pubkeyauthentication yes?
• [ ] O journalctl -u ssh mostra um motivo de rejeicao?
• [ ] Ao usar agent, a chave esta em ssh-add -l?