Como corrigir Permission denied (publickey) no SSH

O que Permission denied (publickey) realmente significa

Permission denied (publickey) significa que o cliente enviou uma ou mais chaves públicas e o servidor não aceitou nenhuma. A rede está funcional e o sshd está em execução: a recusa ocorre na última etapa da autenticação. A correção nunca deve ser baseada em tentativa e erro, porque ssh -v indica qual das cinco causas está presente.

As palavras entre parênteses são os métodos que o servidor aceitava. Permission denied (publickey), por si só, significa que o início de sessão com palavra-passe está desativado nesse servidor, pelo que não existe uma palavra-passe alternativa. Permission denied (publickey,password) significa que as palavras-passe estavam disponíveis e que também falhou essa tentativa.

Uma única mensagem abrange cinco falhas distintas e é vaga de propósito. Um servidor que respondesse "utilizador inexistente" ou "essa chave não está instalada" ajudaria qualquer pessoa a identificar contas válidas. Por isso, não comece por trocar chaves nem editar ficheiros de configuração. Execute um comando, leia três linhas da saída e reduza as cinco causas possíveis a uma.

Execute ssh -v primeiro e leia três linhas

Repita o comando que falhou, adicionando -v:

ssh -v deploy@203.0.113.10

Uma execução resumida, mas realista, é semelhante a esta:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

Três linhas contêm todas as informações necessárias.

Authenticating to 203.0.113.10:22 as 'deploy' é o nome de utilizador que será efetivamente utilizado. Não é o nome que pretendia usar, mas o que o ssh determinou a partir da linha de comandos, de ~/.ssh/config ou do seu nome de login local.

Authentications that can continue: publickey é a lista de métodos aceites pelo servidor, enviada antes de qualquer chave ser testada. Se publickey não aparecer nessa primeira lista, o servidor tem o login com chave pública desativado. Nesse caso, nenhuma chave poderá funcionar.

Offering public key: ... é uma linha por cada chave que o cliente enviou efetivamente, indicando o ficheiro de origem e a respetiva impressão digital SHA256. Uma chave sem uma linha Offering nunca foi enviada para o servidor.

Agora divida o problema em dois:

• Não existe uma linha Offering public key para a chave esperada. A falha está na sua máquina, porque o servidor ainda não recebeu a sua chave.
• A chave é apresentada e Authentications that can continue: publickey volta a aparecer. O servidor recebeu essa chave e recusou-a. Portanto, a falha está no servidor.

As causas abaixo estão ordenadas pela frequência com que acabam por ser a resposta.

Causa 1: está a ligar-se com o nome de utilizador errado

A causa mais comum também é a menos interessante. O sshd, o daemon de servidor SSH (secure shell), nunca informa que uma conta não existe. Executa toda a troca para um nome de utilizador inventado e recusa a ligação no fim com a mesma mensagem, porque divulgar nomes de contas válidos ajuda um atacante. Um erro no nome de utilizador parece exatamente uma chave danificada.

Verifique a linha Authenticating to ... as antes de qualquer outra coisa. Se indicar o seu login no portátil em vez da conta no servidor, não incluiu o nome de utilizador no comando.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

A conta predefinida depende da imagem criada pelo fornecedor. Em agosto de 2026, as imagens cloud do Ubuntu normalmente incluem uma conta ubuntu, as imagens Debian incluem debian ou admin, Rocky Linux e AlmaLinux incluem rocky e almalinux, e muitos fornecedores de VPS instalam a sua chave diretamente em root. O painel de controlo do fornecedor regista a conta que criou. Nenhum comando executado fora do servidor pode consultar essa informação.

Um bloco Host em ~/.ssh/config também define o nome de utilizador e tem precedência sobre o seu nome de login local:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Se criou a conta e depois não conseguiu iniciar sessão com ela, provavelmente a chave foi instalada para o utilizador predefinido da imagem e nunca foi copiada para a nova conta. Esse passo faz parte dos primeiros dez minutos num VPS novo e é fácil ignorá-lo.

Causa 2: a chave que pensa estar a enviar não é a chave que está a ser enviada

Por predefinição, o ssh oferece apenas as chaves mantidas pelo ssh-agent e um conjunto fixo de nomes de ficheiro em ~/.ssh: id_ed25519, id_ecdsa, id_rsa e as variantes de hardware e DSA desses nomes. Uma chave guardada como ~/.ssh/vps-prod fica invisível para o ssh até ser indicada explicitamente. É por isso que a saída detalhada não mostra nenhuma linha Offering public key para essa chave.

Indique o ficheiro e impeça que as chaves do agente sejam usadas no lugar dele:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

-i, por si só, não é suficiente quando o agente contém chaves, porque o ssh continua a oferecer primeiro as chaves do agente e só depois o ficheiro indicado. Isto é importante porque o servidor contabiliza cada chave recusada para MaxAuthTries, que por predefinição é 6. Um agente com sete chaves pode atingir o limite antes de a chave correta ser testada. A mensagem passa então a ser:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

IdentitiesOnly=yes limita a tentativa ao ficheiro indicado. Liste o que o agente contém com ssh-add -l e limpe-o com ssh-add -D se tiver acumulado chaves antigas ao longo dos anos. Depois, registe estas definições para que o próximo início de sessão não dependa da memorização de flags:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

Existe ainda outra armadilha do lado do cliente. O ssh recusa usar uma chave privada que possa ser lida por outras contas na sua própria máquina. Apresenta um aviso e ignora a chave. Assim, a chave nunca é oferecida e o servidor nunca a recebe:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod corrige o problema. A transferência de uma chave através de uma pen USB ou de uma partilha do Windows é a forma habitual de o modo se perder. A localização das chaves e os nomes a atribuir-lhes são abordados em Noções básicas sobre a gestão de chaves SSH.

Causa 3: a chave pública nunca chegou a authorized_keys

Se ssh -v mostrar que a chave foi enviada e o servidor continuar a recusá-la, a questão seguinte é saber se essa chave está no ficheiro authorized_keys da conta. Abra a consola do seu fornecedor para verificar, porque não consegue iniciar sessão por SSH para consultar o ficheiro.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

ssh-keygen -lf num ficheiro authorized_keys apresenta uma impressão digital por entrada:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

Compare-as com a impressão digital na linha Offering public key. Se não estiver na lista, a chave não está instalada nessa conta, independentemente do que se lembra de ter feito.

Quatro formas comuns de isto falhar:

• Colou a chave privada em vez do ficheiro .pub. Uma linha de chave pública começa por ssh-ed25519 ou ssh-rsa. Uma chave privada começa por -----BEGIN OPENSSH PRIVATE KEY-----.
• A colagem foi dividida em várias linhas. Cada entrada tem de ocupar exatamente uma linha. Uma chave dividida é lida como várias entradas incompletas e não corresponde a nada.
• A chave foi colocada em /root/.ssh/authorized_keys, mas inicia sessão como deploy, ou vice-versa. O ficheiro é específico de cada conta. Não existe um ficheiro partilhado.
• A caixa "add my key" do fornecedor escreveu a chave apenas no utilizador predefinido da imagem. Por isso, a conta criada posteriormente tem um diretório .ssh vazio.

A forma segura de adicionar uma chave a partir da consola, como root, é:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

Execute novamente sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys. A nova impressão digital deverá estar agora na lista. A partir de uma máquina que ainda consiga iniciar sessão com uma palavra-passe, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 faz o mesmo trabalho e define corretamente as permissões.

Causa 4: por que o sshd ignora authorized_keys quando as permissões são demasiado abertas

StrictModes yes é o valor predefinido do sshd. Com essa definição, o sshd recusa-se a ler authorized_keys se esse ficheiro, o diretório .ssh ou o diretório inicial da conta puderem ser escritos por alguém que não seja o proprietário. O motivo é direto: se o grupo ou outros utilizadores puderem escrever no seu diretório inicial, qualquer conta com esse acesso poderá substituir authorized_keys e assumir o login. O sshd trata um caminho não confiável como se nenhuma chave existisse.

O cliente apresenta a mensagem simples Permission denied. O log do servidor regista o motivo real:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

ou, quando o problema está no próprio ficheiro:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

O que o sshd aceita:

• O diretório inicial: não pode permitir escrita pelo grupo nem por outros utilizadores. 755, 750 e 700 são aceites. 775 e 777 falham.
• ~/.ssh: modo 700.
• ~/.ssh/authorized_keys: modo 600.
• Proprietário: os três devem pertencer à conta com que inicia sessão, e não a root.

O proprietário é tão importante como o modo. Um ficheiro dentro de /home/deploy/.ssh pertencente a root falha na mesma verificação. É isso que acontece quando o cria com sudo nano e se esquece de o devolver à conta correta. Corrija ambos de uma vez:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

O último comando apresenta o resultado. O diretório inicial deve ter drwxr-xr-x ou permissões mais restritivas, e drwx------ em .ssh. Se estas cadeias ainda não forem claras, leia como ler uma cadeia de permissões como drwxr-xr-x antes de alterar os modos num servidor em produção.

No Rocky Linux e no AlmaLinux, inclua o SELinux (security-enhanced Linux) na lista de possíveis causas. Um diretório .ssh criado por um método invulgar pode ter o rótulo de ficheiro incorreto. Nesse caso, o sshd não consegue ler o ficheiro, mesmo que os modos estejam corretos. sudo restorecon -Rv /home/deploy/.ssh repõe os rótulos, e sudo ausearch -m avc -ts recent mostra se o SELinux foi o componente que recusou o acesso.

Causa 5: o sshd está configurado para recusar a sua ligação

Ler /etc/ssh/sshd_config não é suficiente num sistema Ubuntu ou Debian atual. Esse ficheiro começa com Include /etc/ssh/sshd_config.d/*.conf, e o OpenSSH mantém o primeiro valor encontrado para cada definição. Por isso, um ficheiro drop-in como 50-cloud-init.conf é lido primeiro e prevalece sobre qualquer alteração feita mais abaixo no ficheiro principal. É por isso que uma edição pode parecer correta e não alterar absolutamente nada.

Peça ao sshd a configuração que está realmente a utilizar:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

Uma resposta correta tem este aspeto:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

Procure o seguinte na sua própria saída:

• pubkeyauthentication no. Nenhuma chave será aceite. Isto também aparece em ssh -v como uma lista Authentications that can continue: inicial sem publickey.
• authorizedkeysfile a apontar para outro local, por exemplo /etc/ssh/authorized_keys/%u. Nesse caso, o ficheiro no diretório pessoal é completamente ignorado, e as regras de permissões da causa 4 aplicam-se ao novo caminho.
• allowusers ou allowgroups presentes. Qualquer conta que não esteja listada é recusada exatamente com este erro e sem explicação. denyusers e denygroups fazem o mesmo no sentido inverso.
• permitrootlogin no enquanto tenta iniciar sessão como root. prohibit-password é a definição intermédia útil: root pode utilizar uma chave, mas não uma palavra-passe.

Os blocos Match não aparecem num sshd -T simples, porque o resultado depende de quem está a ligar-se. Consulte uma ligação específica:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

Outra definição afeta as chaves mais antigas. O OpenSSH 8.8 deixou de aceitar assinaturas SHA-1 (ssh-rsa) por predefinição, pelo que uma chave RSA que funcionou durante anos pode deixar de funcionar imediatamente após uma atualização do servidor. O cliente indica isso claramente:

debug1: send_pubkey_test: no mutual signature algorithm

A correção correta é criar uma chave nova: ssh-keygen -t ed25519 -C "deploy@vps-prod", e depois instalar o ficheiro .pub conforme mostrado acima. Definir PubkeyAcceptedAlgorithms +ssh-rsa no servidor reativa as assinaturas antigas e permite-lhe entrar hoje, mas deve ser tratado como uma forma de aceder ao servidor, não como a solução final. As restantes definições do lado do servidor que vale a pena rever estão em proteger o servidor SSH num VPS.

Como provar que uma chave privada corresponde à chave pública instalada

Grande parte da incerteza deste erro vem de não saber se dois ficheiros formam um par. Um comando responde a essa questão:

ssh-keygen -y -f ~/.ssh/vps-prod

Esse comando apresenta a chave pública derivada da chave privada. Nunca lê o ficheiro .pub que está ao lado dela. Por isso, mostra o valor real da chave privada, e não o valor que um ficheiro .pub desatualizado afirma ter. Se a chave tiver uma frase-passe, o comando pede-a. Isso também prova que ainda conhece a frase-passe.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

O primeiro comando apresenta a impressão digital de um ficheiro de chave pública. O segundo apresenta as impressões digitais que o seu agente tem em memória. Compare quatro representações da mesma cadeia: a impressão digital na linha Offering public key de ssh -v, a impressão digital do seu ficheiro .pub, as impressões digitais em ssh-keygen -lf no authorized_keys do servidor e a impressão digital no log do servidor. O ponto em que deixam de coincidir identifica a origem do problema.

Leia o log do servidor enquanto o início de sessão falha

O cliente não recebe de propósito nenhuma informação útil. O servidor regista o motivo real. Inicie um processo que acompanhe o log na sessão de consola e execute depois, a partir do seu portátil, o comando ssh que está a falhar.

sudo journalctl -u ssh -f

O Ubuntu 24.04 não instala o rsyslog por predefinição, pelo que /var/log/auth.log pode não existir nesse sistema. No Rocky Linux e no AlmaLinux, a unidade chama-se sshd e os mesmos registos também são gravados em /var/log/secure.

Defina LogLevel VERBOSE na configuração do sshd e recarregue o serviço. Cada tentativa passa então a registar a impressão digital que o servidor recebeu efetivamente:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

Essa linha indica de que lado está o problema. Uma impressão digital que reconhece significa que a sua chave chegou ao servidor e foi rejeitada por este. Nesse caso, analise as causas 3, 4 e 5. Uma impressão digital que não reconhece significa que o cliente enviou uma chave diferente da pretendida. Nesse caso, volte à causa 2.

Se o log continuar pouco claro, execute um segundo sshd noutra porta, em modo de depuração. O processo permanece em primeiro plano, atende uma ligação, apresenta o raciocínio e termina:

sudo /usr/sbin/sshd -ddd -p 2222

Na sessão de consola do mesmo servidor, ligue-se a esse processo através do endereço de loopback:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

Usar 127.0.0.1 impede que a firewall interfira no teste. A saída de depuração identifica o ficheiro aberto, a impressão digital comparada e a recusa exata, incluindo linhas como Authentication refused: bad ownership or modes for directory /home/deploy. Prima Ctrl+C quando obtiver a resposta. O sshd real, na porta 22, permanece inalterado durante todo o teste.

Como evitar ficar sem acesso

Cada etapa que altera a configuração do servidor precisa de uma forma de acesso que não dependa de SSH. Configure-a enquanto o SSH ainda funciona, e não depois de falhar.

1. Abra a consola do seu provedor, através de serial ou VNC (virtual network computing), e confirme que consegue iniciar sessão por esse meio.
2. Confirme que conhece uma palavra-passe local válida para uma conta com sudo. Se não tiver uma, reponha primeiro a palavra-passe de root através da consola do provedor.
3. Mantenha a sessão SSH atual aberta. Uma sessão aberta sobrevive a systemctl restart ssh, por isso continua a ser uma forma de recuperar o acesso se a nova configuração estiver incorreta.
4. Verifique a sintaxe antes de reiniciar: sudo sshd -t não apresenta saída quando o ficheiro é válido e apresenta o ficheiro e o número da linha quando não é.
5. Abra um segundo terminal e inicie uma nova sessão antes de fechar a primeira. Uma configuração incorreta impede novos logins, mas não afeta os existentes. Por isso, a sessão que está a utilizar não permite confirmar se a alteração funcionou.

Reinicie com sudo systemctl restart ssh no Debian e no Ubuntu, ou com sudo systemctl restart sshd no Rocky Linux e no AlmaLinux. No Ubuntu 24.04, o sshd é iniciado a partir de uma unidade de socket. Por isso, uma alteração a Port ou ListenAddress também requer sudo systemctl restart ssh.socket antes de produzir efeitos.

FAQ

Por que recebo Permission denied (publickey) quando a mesma chave funciona noutro servidor?

Porque a chave está correta e o problema está relacionado com ela. Execute ssh -v e procure a linha Offering public key. Se a sua chave não estiver listada, o ssh nunca a enviou: o ficheiro não está em ~/.ssh com um nome predefinido e não foi carregado no agente, por isso adicione -i /path/to/key -o IdentitiesOnly=yes. Se a chave estiver listada e o servidor continuar a recusá-la, essa chave não está no authorized_keys da conta, o caminho até ela permite escrita pelo grupo ou o sshd bloqueia o utilizador. O log do servidor permite distinguir estes casos.

Como vejo qual é a chave que o SSH está realmente a enviar?

ssh -v host imprime uma linha debug1: Offering public key: por chave. Cada linha identifica o ficheiro de origem e uma impressão digital SHA256. ssh-add -l lista as impressões digitais que o agente tem em memória. ssh-keygen -lf ~/.ssh/id_ed25519.pub imprime a impressão digital de um único ficheiro de chave, e ssh-keygen -y -f ~/.ssh/id_ed25519 imprime a chave pública que deriva realmente de uma chave privada. Para o login ser bem-sucedido, a impressão digital da linha Offering também tem de aparecer no resultado de ssh-keygen -lf executado contra o authorized_keys do servidor.

Por que o sshd ignora o meu ficheiro authorized_keys?

Porque StrictModes está ativo por predefinição, e o ficheiro, o diretório .ssh ou o diretório home permite escrita pelo grupo ou por outros utilizadores, ou pertence à conta errada. O sshd não confia num caminho que outra pessoa possa alterar, por isso comporta-se como se não existisse nenhuma chave. Defina o diretório home como 755 ou mais restritivo, .ssh como 700, authorized_keys como 600, e faça com que os três pertençam à conta de login. Com LogLevel VERBOSE, o servidor regista Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

A minha chave deixou de funcionar logo depois de uma atualização do servidor. O que mudou?

Se for uma chave RSA, a causa mais provável é a alteração relacionada com SHA-1. O OpenSSH 8.8 desativou por predefinição as assinaturas SHA-1 ssh-rsa, por isso uma chave que só consiga assinar dessa forma passa a ser recusada. A saída detalhada do cliente mostra debug1: send_pubkey_test: no mutual signature algorithm. Gere uma chave moderna com ssh-keygen -t ed25519 e instale o respetivo ficheiro .pub. Se precisar de acesso imediato, PubkeyAcceptedAlgorithms +ssh-rsa no servidor reativa as assinaturas antigas. Remova essa linha assim que a nova chave funcionar.

Editei o sshd_config e agora não consigo iniciar sessão. Como recupero o acesso?

Use a consola do seu fornecedor, que não passa pelo SSH. Inicie sessão nessa consola com uma palavra-passe local, execute sudo sshd -t para ver o erro de sintaxe e o número da linha, reverta a alteração e reinicie o serviço. Depois consulte sudo sshd -T para confirmar os valores ativos, porque um ficheiro em /etc/ssh/sshd_config.d/ pode estar a substituir a configuração principal. Se não tiver uma palavra-passe local, redefina primeiro a palavra-passe de root na consola e depois corrija o ficheiro.