O erro Permission denied (publickey). é um dos problemas SSH mais frustrantes de diagnosticar porque pode ter múltiplas causas, e a mensagem de erro em si fornece muito pouca informação sobre o que deu errado. Este artigo foca em uma causa particularmente difícil — diretórios home criptografados — e também cobre as outras causas comuns e suas soluções.

O Problema

Você configurou a autenticação por chave SSH corretamente no seu servidor Ubuntu. Tudo funciona perfeitamente — até você reiniciar o servidor. Após o reinício, você obtém:

Permission denied (publickey).

Você acessa o servidor via console, e tudo parece estar bem — as chaves estão no lugar certo, as permissões parecem corretas. Você tenta SSH novamente e funciona. Reinicia o servidor ou o serviço SSH, e o erro retorna.

Este comportamento intermitente é o sintoma chave que aponta para um diretório home criptografado como a causa raiz.

Por Que Diretórios Home Criptografados Quebram a Autenticação SSH por Chave

Quando você instala o Ubuntu e escolhe criptografar seu diretório home, o sistema usa eCryptfs para criptografar ~/.Private e montá-lo no seu diretório home ao fazer login. Isto é o que acontece:

  1. Antes do login: O conteúdo do seu diretório home está criptografado. O daemon SSH tenta ler ~/.ssh/authorized_keys mas não consegue porque o diretório está criptografado.
  2. Durante o login por console: Você insere sua senha, o que aciona a descriptografia e montagem do seu diretório home.
  3. Após o login: ~/.ssh/authorized_keys agora está legível, então a autenticação por chave SSH funciona.

Isso cria o padrão confuso onde as chaves SSH funcionam após fazer login manualmente mas falham após um reinício.

Ponto chave: Servidores na nuvem (AWS, Azure, DigitalOcean, etc.) não criptografam diretórios home por padrão, por isso este problema tipicamente afeta apenas servidores que você instalou por conta própria onde escolheu a opção de criptografia.

Diagnosticando o Problema

Passo 1: Habilitar Saída SSH Detalhada

Conecte-se com máxima verbosidade para ver exatamente onde a autenticação falha:

ssh -vvv usuario@seu-servidor

Procure por linhas como:

debug1: Offering public key: /home/seuusuario/.ssh/id_ed25519
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

A resposta type 51 significa que o servidor rejeitou a chave.

Passo 2: Verificar Logs do Servidor

No servidor (acessado via console), examine o log de autenticação:

sudo tail -50 /var/log/auth.log

Para problemas de diretório home criptografado, você pode ver:

sshd[1234]: Could not open authorized keys '/home/usuario/.ssh/authorized_keys': No such file or directory

Esta mensagem aparece porque o diretório criptografado parece vazio para o daemon SSH.

Passo 3: Verificar a Criptografia do Diretório Home

Verifique se seu diretório home está criptografado:

ls -la /home/

Se você vir um diretório .ecryptfs ou .Private, seu diretório home usa criptografia:

ls -la /home/usuario/
# Se criptografado e não montado, você pode ver:
# .ecryptfs  .Private  Access-Your-Private-Data.desktop  README.txt

Você também pode verificar:

mount | grep ecryptfs

Solução 1: Armazenar Chaves SSH Fora do Diretório Home Criptografado (Recomendado)

A melhor abordagem é configurar o SSH para ler chaves autorizadas de um local fora do diretório home criptografado.

Criar o Diretório Alternativo de Chaves

sudo mkdir -p /etc/ssh/authorized_keys

Copiar Suas Chaves Autorizadas

sudo cp ~/.ssh/authorized_keys /etc/ssh/authorized_keys/$USER
sudo chown root:root /etc/ssh/authorized_keys/$USER
sudo chmod 644 /etc/ssh/authorized_keys/$USER

Atualizar a Configuração SSH

Edite a configuração do daemon SSH:

sudo nano /etc/ssh/sshd_config

Encontre a diretiva AuthorizedKeysFile e mude para:

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

O %u é substituído pelo nome do usuário durante a autenticação.

Reiniciar SSH

sudo systemctl restart sshd

Testar a Configuração

Da sua máquina local:

ssh usuario@seu-servidor

Isso agora deve funcionar mesmo após um reinício porque /etc/ssh/authorized_keys/ não está dentro do diretório home criptografado.

Importante: Quando adicionar novas chaves SSH no futuro, você precisa adicioná-las a /etc/ssh/authorized_keys/nomeusuario em vez de ~/.ssh/authorized_keys.

Para um tutorial detalhado desta abordagem, consulte: Como armazenar sua chave pública SSH em um diretório diferente.

Solução 2: Descriptografar o Diretório Home

Se você decidir que não precisa mais da criptografia do diretório home:

# Certifique-se de estar conectado como o usuário
ecryptfs-migrate-home -u $USER

Aviso: Faça backup dos seus dados antes de tentar isso. A descriptografia do diretório home pode falhar se não houver espaço em disco suficiente (você precisa de aproximadamente o dobro do espaço do seu diretório home temporariamente).

Outras Causas Comuns de ‘Permission denied (publickey)’

Se seu diretório home não está criptografado, o erro provavelmente vem de uma destas causas:

Permissões de Arquivo Incorretas

O SSH é muito rigoroso com permissões. O seguinte deve estar configurado corretamente:

# Diretório home: sem escrita para grupo/outros
chmod 755 ~
# ou
chmod 700 ~

# Diretório .ssh: apenas proprietário
chmod 700 ~/.ssh

# authorized_keys: apenas leitura/escrita do proprietário
chmod 600 ~/.ssh/authorized_keys

# Chave privada (no seu cliente): apenas leitura do proprietário
chmod 600 ~/.ssh/id_ed25519

Chave Não Adicionada ao authorized_keys

Verifique se sua chave pública está no arquivo authorized_keys do servidor:

cat ~/.ssh/authorized_keys

Compare com sua chave pública local:

# Na sua máquina local
cat ~/.ssh/id_ed25519.pub

Agente SSH Não Carregado

Se sua chave usa uma frase-senha e o agente SSH não está em execução:

# Iniciar o agente
eval "$(ssh-agent -s)"

# Adicionar sua chave
ssh-add ~/.ssh/id_ed25519

Tipo de Chave Incorreto

Servidores mais antigos podem não suportar tipos de chave mais novos como Ed25519. Tente gerar uma chave RSA:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_legacy
ssh-copy-id -i ~/.ssh/id_rsa_legacy.pub usuario@servidor

Configuração do Servidor Bloqueando Autenticação por Chave Pública

Verifique se o servidor permite autenticação por chave pública:

sudo grep -E "PubkeyAuthentication|AuthorizedKeysFile" /etc/ssh/sshd_config

Certifique-se de que:

PubkeyAuthentication yes

SELinux ou AppArmor Bloqueando Acesso

Em sistemas com controle de acesso obrigatório:

# Verificar SELinux
sudo restorecon -R ~/.ssh/

# Verificar AppArmor
sudo aa-status

Lista Rápida de Verificação

VerificaçãoComando
Saída SSH detalhadassh -vvv usuario@servidor
Log de autenticaçãosudo tail -50 /var/log/auth.log
Home criptografado?mount | grep ecryptfs
Permissões .sshls -la ~/.ssh/
Conteúdo authorized_keyscat ~/.ssh/authorized_keys
Configuração SSHsudo sshd -T | grep -i pubkey
Chaves do agente SSHssh-add -l

Resumo

O erro Permission denied (publickey) causado por diretórios home criptografados é particularmente insidioso porque funciona de maneira intermitente — a autenticação por chave SSH tem sucesso após login manual mas falha após um reinício. A solução recomendada é armazenar chaves autorizadas fora do diretório home criptografado atualizando AuthorizedKeysFile no sshd_config.

Para outras causas deste erro, verifique sistematicamente as permissões de arquivo, confirme que a chave está no authorized_keys, certifique-se de que o agente SSH está em execução e revise o sshd_config do servidor. Usar ssh -vvv e verificar /var/log/auth.log quase sempre revelará a causa raiz.

Artigos Relacionados