Permission denied (publickey).

A mensagem vem precedida de `user@host:`. A lista entre parênteses mostra os métodos que o servidor ainda permite, por exemplo, `(publickey,password)` ou `(publickey,gssapi-keyex,gssapi-with-mic)`.

O que significa

A conexão SSH e a verificação do host deram certo, mas o servidor não aceitou nenhuma das chaves públicas que o cliente ofereceu, e a autenticação por chave pública é o único método que ele permite (a lista entre parênteses). O cliente nunca fica sabendo por que uma chave foi recusada — o motivo só aparece no log do servidor. No GitHub, no GitLab e no Bitbucket, a mesma mensagem significa que nenhuma das suas chaves está registrada na conta (ou como chave de implantação) com acesso a esse repositório.

Por que acontece

• A chave certa não é oferecida

  comum

  A chave não está no agente, não está em um caminho padrão (`~/.ssh/id_ed25519`, `id_ecdsa`, `id_rsa`) e não foi indicada com `-i` nem com `IdentityFile`. Com muitas chaves no agente, o servidor pode desconectar (MaxAuthTries) antes de a chave certa ser testada.

• A chave não está no authorized_keys desse usuário

  comum

  Instalada para outro usuário ou host, removida durante uma reinstalação ou (em serviços de hospedagem Git) adicionada a uma conta diferente da que tem acesso ao repositório.

• O sshd ignora o authorized_keys por causa das permissões

  ocasional

  Com `StrictModes yes` (o padrão), um diretório home, um `~/.ssh` ou um `authorized_keys` com permissão de escrita para o grupo ou para todos faz o sshd recusar o arquivo. O log do servidor registra “Authentication refused: bad ownership or modes”.

• O algoritmo de assinatura da chave não é aceito

  ocasional

  Servidores OpenSSH 8.8+ rejeitam chaves RSA quando clientes e bibliotecas antigos as usam com o algoritmo `ssh-rsa` (SHA-1); o suporte a chaves DSA foi removido por completo no OpenSSH 10. O servidor registra “not in PubkeyAcceptedAlgorithms”.

• Nome de usuário remoto errado

  ocasional

  `ssh server` faz login com seu nome de usuário local. Imagens de nuvem esperam `ubuntu`, `ec2-user`, `admin`; serviços de hospedagem Git sempre esperam `git@`.

Como corrigir

1. 1.

   Ver quais chaves são oferecidas

   O `ssh -v` lista cada chave que o cliente oferece e se o servidor a aceitou; o `ssh -G` mostra o usuário e os arquivos de identidade efetivos depois de aplicada toda a configuração.

   ssh -v deploy@server.example.com 2>&1 | grep -E "Offering|Server accepts|Authentications that can continue|send_pubkey_test"
   ssh-add -l                                  # keys the agent offers
   ssh -G deploy@server.example.com | grep -E "^(user|identityfile|identitiesonly) "

2. 2.

   Fixar a identidade por host

   `IdentityFile` junto com `IdentitiesOnly yes` oferece exatamente uma chave e evita “Too many authentication failures” com agentes que guardam muitas chaves.

   # ~/.ssh/config
   Host server.example.com
     User deploy
     IdentityFile ~/.ssh/deploy_ed25519
     IdentitiesOnly yes

3. 3.

   Corrigir o lado do servidor e ler o log dele

   Instale a chave pública para o usuário correto, com permissões restritas, e procure no log do sshd o motivo específico da recusa.

   # On the server: install the key and fix modes (sshd ignores keys in group/world-writable paths)
   install -d -m 700 ~/.ssh && cat deploy_ed25519.pub >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
   sudo journalctl -u ssh --since "10 min ago" | grep -E "Authentication refused|not in PubkeyAccepted|Failed publickey"

← Ver toda a base de erros de assinatura