Permission denied publickey: como resolver no SSH

Entenda o erro Permission denied (publickey) e siga um roteiro para conferir usuário, chave no agente, opção -i, permissões e a configuração do servidor.

Por Redação Eleven Host · @robson.direitodigital · 29 de outubro de 2026 · 8 min de leitura

O erro Permission denied publickey, escrito na tela como Permission denied (publickey), aparece quando o servidor SSH recusa o login porque nenhuma chave aceita foi apresentada. A causa pode estar no usuário, na chave, no agente ou nas permissões.

Este guia mostra um roteiro em ordem para achar a causa: ler a saída do ssh -v, conferir o usuário, ver se a chave está carregada, indicar o arquivo com -i, ajustar as permissões e olhar o lado do servidor. Se o seu servidor é uma VPS, o guia completo de servidor VPS explica o que é uma VPS e como escolher. Os exemplos usam exemplo.com e usuario como valores fictícios.

O que a mensagem significa

A mensagem diz, em termos simples, que o servidor não aceitou nenhuma das chaves que o seu computador ofereceu. Por isso o caminho é investigar duas pontas: o que o seu computador está oferecendo e o que o servidor tem cadastrado para o seu usuário.

Causas possíveis

Estas são as situações que podem produzir o erro:

• Chave pública ausente no servidor: ela não está no arquivo authorized_keys do usuário.
• Usuário errado no comando: o login foi tentado com um nome que não é o da conta que tem a chave.
• Chave privada com nome fora do padrão: o ssh não procurou o arquivo e faltou o -i.
• Permissões abertas demais: o ssh pode ignorar a chave privada se outras pessoas têm acesso ao arquivo.
• Chave não carregada no agente: o agente não tem a chave que o servidor espera.

Passo 1: rode o ssh com -v

O primeiro passo é pedir mais detalhes ao ssh. A opção -v imprime mensagens de depuração, e pode ser repetida até 3 vezes (-vvv) para mostrar mais detalhes:

ssh -v usuario@exemplo.com

Na saída, procure as linhas que falam de identity file. Uma linha com type -1 significa que o arquivo não foi encontrado. Se isso aparece para a chave que você esperava usar, vale conferir o nome e o local do arquivo.

Como ler a saída sem se perder

A saída do ssh -v é longa, e não é preciso entender cada linha. Procure três coisas: as linhas de identity file, que mostram quais arquivos de chave o ssh tentou ler; o usuário que aparece na conexão; e as últimas linhas, onde o servidor informa que recusou. Copie esses trechos para um bloco de notas: eles ajudam você a comparar o antes e o depois de cada mudança, e também podem ajudar se você abrir um chamado.

Se precisar de mais detalhe, repita o comando com -vv ou -vvv. Cada letra a mais acrescenta mensagens de depuração. Antes de colar a saída em um fórum ou chat, confira se não há nomes de servidores internos que você prefira manter em sigilo.

Passo 2: confirme o usuário

Usuário errado causa esse erro. Em cada serviço o nome de usuário pode mudar: no GitHub, por exemplo, o usuário tem de ser git. Numa VPS, use o usuário certo da sua conta. Confira o nome que foi criado e compare com o que você digitou antes do @.

Rode o ssh com o seu usuário, sem sudo. Se você precisa criar uma conta de administração na VPS, veja Criar usuário sudo na VPS Ubuntu: passo a passo.

Passo 3: veja se a chave está carregada no agente

Se você usa o agente do ssh, liste as chaves carregadas:

ssh-add -l -E sha256

Se não aparecer nada, a chave não foi carregada: carregue a sua chave ou gere uma nova. Para gerar uma chave e cadastrá-la na VPS, siga Como criar chave SSH e entrar na VPS sem senha.

Quer um servidor para configurar o acesso por chave? A VPS Plano Bronze sai a partir de R$ 17,00/mês; confira na loja o que o plano inclui. Ver planos de VPS

Passo 4: indique o arquivo da chave com -i

Segundo o manual do ssh, a opção -i seleciona o arquivo de onde a identidade (chave privada) para a autenticação por chave pública é lida. O ssh procura por padrão alguns nomes em ~/.ssh/, entre outros:

• ~/.ssh/id_rsa
• ~/.ssh/id_ecdsa
• ~/.ssh/id_ecdsa_sk
• ~/.ssh/id_ed25519
• ~/.ssh/id_ed25519_sk

Se a sua chave tem outro nome, diga qual é:

ssh -i ~/.ssh/ARQUIVO usuario@exemplo.com

Troque ARQUIVO pelo nome do arquivo da chave privada, o que não leva a extensão .pub. O arquivo com .pub é a chave pública, a que vai para o servidor.

Passo 5: ajuste as permissões

O manual do ssh recomenda que a pasta ~/.ssh/ tenha leitura, gravação e execução só para o seu usuário e fique inacessível aos outros. Para o arquivo ~/.ssh/authorized_keys, a recomendação é leitura e gravação só para o usuário. O manual diz ainda que o ssh ignora um arquivo de chave privada que seja acessível por outros.

Os comandos comuns para ajustar isso são:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

chmod 600 ~/.ssh/id_ed25519

O último comando usa o nome id_ed25519 como exemplo; troque pelo nome da sua chave privada. O segundo vale para o servidor; o terceiro vale para o computador de onde você conecta; o primeiro vale para a pasta ~/.ssh nos dois lados.

Passo 6: confira o lado do servidor

Se o seu computador oferece a chave certa e mesmo assim o servidor recusa, olhe a configuração do servidor. O arquivo é o /etc/ssh/sshd_config. Segundo o manual do sshd_config:

• AuthorizedKeysFile: o padrão é .ssh/authorized_keys .ssh/authorized_keys2. Os arquivos só são conferidos para usuários válidos.
• PubkeyAuthentication: define se o login por chave pública é autorizado. O padrão é yes.
• StrictModes: com o padrão yes, o sshd confere os modos e o dono dos arquivos do usuário e do diretório home antes de aceitar o login.

Por causa do StrictModes, as permissões do passo 5 também importam no servidor. Se você mudar algo no arquivo sshd_config, reinicie o serviço ssh para a mudança valer. Faça isso com cuidado e mantenha uma sessão aberta enquanto testa, para não perder o acesso.

Depois de resolver o acesso, para proteger o SSH contra tentativas repetidas de login, veja o guia Fail2ban na VPS: como instalar e proteger o SSH.

Erros comuns ao corrigir

• Colar a chave privada no servidor: o que vai no authorized_keys é a chave pública, o arquivo com .pub. A privada fica só com você.
• Mudar vários itens de uma vez: altere um ponto por vez e repita o ssh -v, para saber o que resolveu.
• Fechar a sessão que ainda funciona: se você tem uma sessão aberta no servidor, mantenha-a enquanto testa uma nova.
• Esquecer de reiniciar o ssh: mudanças no sshd_config só valem depois de reiniciar o serviço.
• Digitar o usuário de outro serviço: o nome que funciona no GitHub não é o mesmo da sua VPS.

Como evitar o erro no futuro

Depois que o acesso voltar, vale anotar três coisas: o nome do usuário, o nome do arquivo da chave privada e o local onde a chave pública foi cadastrada. Com isso, uma nova tentativa de login fica fácil de conferir. Mantenha também uma cópia da chave privada em lugar seguro e só seu, para o caso de trocar de computador. Se você usa mais de uma chave, o uso de -i com o caminho explícito evita dúvida sobre qual delas está em uso.

Se você ainda não consegue entrar

Se nenhum passo resolveu e você é cliente da Eleven Host, abra um chamado. Informe o usuário usado, o horário da tentativa e a saída do ssh -v com os trechos de identity file e do final da conexão. Não envie a chave privada nem senhas: a chave pública pode ser enviada se for necessária, e a privada deve ficar só com você.

Ainda sem acesso? Abra um chamado com a saída do ssh -v e conte o que já foi conferido. Abrir chamado

Perguntas frequentes

O que significa Permission denied (publickey)?

Significa que o servidor recusou o login porque nenhuma chave aceita foi apresentada. A causa pode estar no usuário, na chave, no agente, nas permissões ou na configuração do servidor.

Como vejo qual chave o ssh está usando?

Rode ssh -v usuario@exemplo.com e leia as linhas de identity file. Uma linha com type -1 indica que o arquivo não foi encontrado.

Minha chave tem um nome diferente de id_ed25519. O que faço?

Use a opção -i com o caminho do arquivo: ssh -i ~/.ssh/ARQUIVO usuario@exemplo.com.

Quais permissões o ssh espera?

Segundo o manual, ~/.ssh/ só para o seu usuário, authorized_keys com leitura e gravação só para o usuário, e a chave privada sem acesso de outros, pois o ssh ignora chave privada acessível por outros.

Preciso usar sudo para conectar?

Rode o ssh com o seu usuário, sem sudo.