Resolvendo Problemas de 'Permission Denied (publickey)' no SSH

Permission denied (publickey) significa que o servidor foi acessível, mas não aceitou nenhuma tentativa de autenticação por chave pública para o usuário que você tentou. Isso restringe o problema. Você não está mais depurando roteamento, DNS ou se a porta SSH está aberta. Você está depurando a identidade: o nome de usuário, a chave privada que seu cliente ofereceu, a chave pública armazenada no servidor e as regras do servidor que decidem se esse login é permitido.

O comando mais rápido e útil é:

ssh -vvv usuario@ip_do_seu_servidor

Procure por Authenticating to ... as 'usuario', depois procure por Offering public key. Se a chave esperada não for oferecida, corrija o cliente. Se a chave esperada for oferecida e rejeitada, corrija o authorized_keys do lado do servidor, a propriedade, as permissões ou a política do daemon SSH.

Causas Comuns do Erro 'Permission Denied (publickey)'

O erro "Permission Denied (publickey)" pode ser causado por várias questões de configuração. Identificar a causa raiz geralmente envolve verificar sistematicamente os seguintes componentes:

• Permissões de Arquivo Incorretas: O SSH é altamente sensível às permissões de arquivos e diretórios por razões de segurança. Permissões incorretas no diretório ~/.ssh local, no arquivo de chave privada ou no diretório ~/.ssh e no arquivo authorized_keys do lado do servidor podem impedir a autenticação.
• Entrada authorized_keys Ausente ou Incorreta: O arquivo authorized_keys do servidor deve conter a chave pública correta para o usuário com o qual você está tentando fazer login. Se a chave estiver ausente, mal formatada ou associada ao usuário errado, a autenticação falhará.
• Associação Incorreta do Par de Chaves: Seu cliente SSH pode estar oferecendo a chave privada errada, ou o servidor pode não ter a chave pública correspondente listada no arquivo authorized_keys.
• Problemas com o Agente SSH: Se você estiver usando um agente SSH, ele pode não estar carregado corretamente com sua chave privada ou pode estar configurado incorretamente.
• Configuração SSH do Lado do Servidor: Embora menos comum para esse erro específico, a configuração do daemon SSH do servidor (sshd_config) pode ter restrições específicas para autenticação por chave pública.

Guia de Solução de Problemas Passo a Passo

Vamos nos aprofundar nas etapas práticas para diagnosticar e corrigir esses problemas.

1. Verificar a Chave Privada Local e as Permissões

Sua configuração SSH local é o primeiro lugar a verificar. Certifique-se de que sua chave privada esteja acessível e tenha as permissões corretas.

Verificando a Existência da Chave Privada

Sua chave privada geralmente está localizada em ~/.ssh/id_ed25519 ou ~/.ssh/id_rsa, mas muitas equipes usam nomes específicos do projeto. Liste suas chaves:

ls -la ~/.ssh

Não faça upload ou cole uma chave privada em authorized_keys. O servidor precisa do conteúdo do arquivo .pub, não da chave privada.

Verificando as Permissões de Arquivo Local

O diretório ~/.ssh e seu arquivo de chave privada devem ter permissões restritivas para evitar acesso não autorizado.

• Diretório ~/.ssh: Deve ser 700 (drwx------).
• Arquivo de chave privada (ex.: id_rsa): Deve ser 600 (-rw-------).

Use o comando chmod para definir as permissões corretas:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa

Dica: Se você estiver usando um nome de chave diferente, substitua id_rsa pelo nome real do seu arquivo de chave privada.

Se você estiver testando uma chave específica, force-a:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod usuario@ip_do_seu_servidor

Isso impede que seu agente ofereça uma longa lista de chaves não relacionadas primeiro.

2. Verificar a Configuração do authorized_keys no Servidor

Esta é geralmente a causa mais comum. O servidor deve ter sua chave pública listada corretamente para o usuário com o qual você está tentando se autenticar.

Acessando o Servidor (se possível)

Se você ainda puder acessar o servidor por outro método (ex.: autenticação por senha, outra conta de usuário ou um console), faça login para verificar o arquivo authorized_keys.

Verificando a Localização do Arquivo authorized_keys

O arquivo authorized_keys geralmente está localizado em ~/.ssh/authorized_keys dentro do diretório home do usuário com o qual você está tentando fazer login.

Verificando as Permissões de Arquivo no Servidor

Semelhante ao lado do cliente, as permissões do lado do servidor são críticas:

• Diretório ~/.ssh no servidor: Deve ser 700 (drwx------).
• Arquivo authorized_keys no servidor: Deve ser 600 (-rw-------).

Certifique-se de que essas permissões estejam definidas corretamente no servidor:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Verifique também a propriedade. O diretório .ssh e o arquivo authorized_keys devem pertencer normalmente à conta com a qual você está fazendo login:

chown -R seunome:seunome ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Se StrictModes estiver habilitado em sshd_config, o OpenSSH pode rejeitar chaves quando o diretório home ou o caminho .ssh for gravável por usuários incorretos.

Verificando o Conteúdo do authorized_keys

Abra o arquivo ~/.ssh/authorized_keys usando um editor de texto (ex.: nano, vim). Cada chave pública deve estar em uma única linha. Certifique-se de que a chave pública que você espera usar esteja presente e formatada corretamente. Ela deve começar com ssh-rsa, ssh-ed25519 ou similar, seguida por uma longa sequência de caracteres e, opcionalmente, um comentário.

Exemplo de entrada authorized_keys:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD... sua_string_de_chave_publica usuario@hostname

Não adicione sua chave privada ao authorized_keys. Apenas a chave pública deve estar aqui.

3. Garantir que a Chave Pública Correta Foi Adicionada

É possível que a chave pública errada tenha sido copiada ou que a chave pública no servidor não corresponda à sua chave privada local.

Recuperando Sua Chave Pública Local

Sua chave pública é a contraparte da sua chave privada. Você pode visualizá-la usando o comando ssh-keygen:

cat ~/.ssh/id_rsa.pub

Este comando exibirá sua chave pública. Compare cuidadosamente esta saída com a entrada no arquivo ~/.ssh/authorized_keys do servidor. Mesmo um único erro de digitação ou caractere ausente fará com que a autenticação falhe.

Para uma comparação mais limpa, imprima a chave pública derivada da chave privada que você está tentando usar:

ssh-keygen -y -f ~/.ssh/id_ed25519_prod

Essa saída deve corresponder a uma linha no authorized_keys do usuário remoto.

Dica: Uma maneira rápida de adicionar sua chave pública se você tiver acesso por senha ao servidor é usar ssh-copy-id.

ssh-copy-id usuario@ip_do_seu_servidor

Este comando anexa automaticamente sua chave pública padrão (~/.ssh/id_rsa.pub) ao arquivo ~/.ssh/authorized_keys no servidor remoto e define as permissões corretas.

4. Especificar a Chave Privada Correta (se não for a padrão)

Se você estiver usando uma chave privada não padrão (ex.: ~/.ssh/minha_outra_chave), você precisa informar ao seu cliente SSH qual chave usar.

Usando a Bandeira -i

Você pode especificar o arquivo de identidade (chave privada) com a opção -i:

ssh -i ~/.ssh/minha_outra_chave usuario@ip_do_seu_servidor

Configurando ~/.ssh/config

Para conveniência, você pode configurar seu cliente SSH para sempre usar uma chave específica para um determinado host:

Crie ou edite o arquivo ~/.ssh/config em sua máquina local e adicione uma entrada como esta:

Host alias_do_seu_servidor
  HostName ip_ou_dominio_do_seu_servidor
  User seu_nome_de_usuario
  IdentityFile ~/.ssh/minha_outra_chave
  IdentitiesOnly yes

Então você pode conectar simplesmente usando:

ssh alias_do_seu_servidor

5. Verificar o Status do Agente SSH

Se você depende de um agente SSH para gerenciar suas chaves, certifique-se de que ele esteja em execução e tenha sua chave carregada.

Verificando se o Agente Está em Execução

echo "$SSH_AUTH_SOCK"

Se isso gerar um caminho, o agente provavelmente está em execução. Se estiver vazio, pode ser necessário iniciar um.

Adicionando Chave ao Agente

Se sua chave não estiver carregada, adicione-a:

ssh-add ~/.ssh/id_rsa

Se for solicitada uma senha, digite-a. Você pode verificar quais chaves foram adicionadas com ssh-add -l.

Se ssh-add -l mostrar muitas chaves não relacionadas e o servidor desconectar após várias tentativas, remova as chaves antigas do agente ou use IdentitiesOnly yes para esse host.

6. Depuração com Modo Verboso

O SSH tem um modo verboso (-v, -vv ou -vvv para níveis crescentes de detalhes) que pode fornecer pistas valiosas sobre onde o processo de autenticação está falhando.

ssh -vvv usuario@ip_do_seu_servidor

Examine a saída em busca de mensagens relacionadas à autenticação de chave, oferta de chaves e respostas do servidor. Isso geralmente aponta diretamente para o problema.

Exemplo de trecho de saída verbosa indicando uma falha de publickey:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: read PEM private key file /home/user/.ssh/id_rsa
debug1: failed to use sshkey: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

Esta saída significa que o cliente tentou id_rsa, o servidor não aceitou e o cliente passou para o próximo método permitido.

7. Revisão do sshd_config no Servidor (Avançado)

Verifique /etc/ssh/sshd_config e quaisquer arquivos em /etc/ssh/sshd_config.d/. Confirme se a autenticação por chave pública está habilitada:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Em seguida, procure por blocos Match perto do final do arquivo. Um bloco Match User, Match Group ou Match Address posterior pode substituir as configurações anteriores para a conta exata que você está testando.

Após qualquer alteração, valide a sintaxe antes de recarregar:

sudo sshd -t
sudo systemctl reload sshd

Alguns sistemas usam ssh como nome do serviço em vez de sshd.

Uma Ordem Confiável de Solução de Problemas

Use a saída verbosa para evitar suposições. Primeiro, confirme o nome de usuário. Em seguida, confirme se o cliente oferece a chave privada que você espera. Depois, confirme se a chave pública correspondente está no authorized_keys do usuário de destino. Em seguida, verifique a propriedade e as permissões. Somente depois que esses itens estiverem limpos, você deve gastar tempo com sshd_config, blocos Match, contextos SELinux ou restrições de conta.

Essa ordem resolve a maioria dos casos de Permission denied (publickey) sem alterações aleatórias e impede que você enfraqueça a segurança do SSH apenas para fazer um login urgente funcionar.