Como corrigir SSH Permission denied (publickey)

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á a funcionar e o sshd está em execução: a recusa ocorre na última etapa da autenticação. Se a sessão terminar antes desse ponto, está perante connection refused ou connection timed out, que é um diagnóstico diferente, com testes diferentes. A correção nunca deve ser baseada em suposições, 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 por palavra-passe está desativado nesse servidor, portanto não há uma palavra-passe alternativa. Permission denied (publickey,password) significa que as palavras-passe estavam disponíveis e que também falhou essa autenticação.

Uma única mensagem abrange cinco falhas diferentes 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 a trocar chaves nem a 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 3 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).

3 linhas contêm tudo o que precisa.

Authenticating to 203.0.113.10:22 as 'deploy' é o nome de utilizador que será efetivamente usado. Não é o nome que pretendia usar: é o nome que o ssh determinou a partir da linha de comandos, de ~/.ssh/config ou do seu nome de início de sessão 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 início de sessão 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 2 partes:

• 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 é oferecida 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 negociação com 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 de digitação no nome de utilizador parece exatamente uma chave avariada.

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 qual foi a conta criada. 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, é provável que a chave tenha sido instalada para o utilizador predefinido da imagem e nunca tenha sido copiada para essa 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 que está a ser enviada

Por predefinição, o ssh oferece apenas as chaves mantidas por ssh-agent e um conjunto fixo de nomes de ficheiros 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é a indicar 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 dela:

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

-i, usado isoladamente, 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 no limite de MaxAuthTries, que por predefinição é 6. Um agente com sete chaves pode atingir o limite antes de a chave correta ser testada. Nesse caso, a mensagem muda para:

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

Se, em vez disso, estiver a ver essa mensagem, o servidor terminou a sessão antes de chegar à sua chave correta. Este é o tema de demasiadas falhas de autenticação. IdentitiesOnly=yes limita a tentativa ao ficheiro que indicou. Liste as chaves que o agente tem carregadas com ssh-add -l e limpe-as com ssh-add -D se tiver acumulado chaves antigas durante anos. Depois, registe as definições para que o próximo início de sessão não dependa de memorizar flags:

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

Existe ainda uma armadilha do lado do cliente. O ssh recusa usar uma chave privada que possa ser lida por outras contas no seu próprio computador. Apresenta um aviso e ignora a chave. Por isso, 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. Mover uma chave através de uma pen USB ou de uma partilha do Windows é a forma habitual de perder as permissões. A localização das chaves e os nomes a atribuir-lhes são explicados 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 próxima questão é 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 sua 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 por 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 o contrário. 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 mais tarde 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 sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys novamente depois disso. 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 padrão do sshd. Com essa configuração, o sshd recusa ler authorized_keys se esse ficheiro, o diretório .ssh ou o diretório pessoal da conta puderem ser escritos por qualquer pessoa que não seja o proprietário. O motivo é direto: se o grupo ou qualquer utilizador puder escrever no seu diretório pessoal, qualquer conta com esse acesso pode substituir authorized_keys e assumir o controlo do login. O sshd trata um caminho não fiável como se não existisse nenhuma chave.

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 pessoal: não pode ter permissão de escrita para o grupo nem para qualquer utilizador. 755, 750 e 700 passam na verificação. 775 e 777 falham.
• ~/.ssh: modo 700.
• ~/.ssh/authorized_keys: modo 600.
• Propriedade: os três devem pertencer à conta usada no login, e não a root.

A propriedade é tão importante como o modo. Um ficheiro dentro de /home/deploy/.ssh pertencente a root falha a mesma verificação. Isto acontece quando o cria com sudo nano e se esquece de devolver a propriedade à 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 mostra o resultado. O diretório pessoal deve ter drwxr-xr-x ou permissões mais restritivas, e drwx------ deve estar definido em .ssh. Se estas sequências ainda não forem claras, leia como ler uma sequência de permissões como drwxr-xr-x antes de alterar 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 processo pouco habitual pode ter o rótulo de ficheiro incorreto. Nesse caso, o sshd não consegue ler o conteúdo, 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 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 tem precedência sobre qualquer alteração feita mais abaixo no ficheiro principal. É por isso que uma alteração pode parecer correta e, ainda assim, não produzir qualquer efeito.

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 normal é semelhante a esta:

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

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

• pubkeyauthentication no. Nenhuma chave será aceite. Isto também aparece em ssh -v como uma lista inicial de Authentications that can continue: sem publickey.
• authorizedkeysfile a apontar para outro local, por exemplo /etc/ssh/authorized_keys/%u. Nesse caso, o ficheiro no diretório inicial é 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 quando está a tentar 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 chaves antigas. O OpenSSH 8.8 deixou de aceitar assinaturas SHA-1 (ssh-rsa) por predefinição. Por isso, uma chave RSA que funcionou durante anos pode deixar de funcionar imediatamente depois de uma atualização do servidor. O cliente indica claramente o motivo:

debug1: send_pubkey_test: no mutual signature algorithm

A correção adequada é 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 volta a ativar as assinaturas antigas e permite aceder ao servidor hoje. Considere isto uma forma de recuperar o acesso, não como a conclusão da correção. As restantes definições do servidor que vale a pena rever estão em reforçar a segurança do servidor SSH num VPS.

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

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

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

Isto imprime a chave pública derivada da chave privada. Nunca lê o ficheiro .pub que está ao lado dela. Assim, mostra o que a chave privada realmente é, e não o que um ficheiro .pub desatualizado afirma. Se a chave tiver uma frase-passe, o comando pede-a. Isso também confirma que ainda conhece a frase-passe.

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

O primeiro comando imprime a impressão digital de um ficheiro de chave pública. O segundo imprime 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 o problema.

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

O cliente não recebe deliberadamente nenhuma informação útil. O servidor regista o motivo real. Inicie um acompanhamento do log na sessão de consola e execute o comando ssh que falha a partir do seu portátil.

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. Todas as tentativas passam 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 em que lado está o problema. Uma impressão digital que reconhece significa que a sua chave chegou ao servidor e foi rejeitada por ele. Nesse caso, verifique 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.

Quando 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 os detalhes da análise e termina:

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

Na sessão de consola do mesmo servidor, ligue-se a ele 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 exclui a firewall do teste. A saída de depuração indica o ficheiro que foi aberto, a impressão digital que foi comparada e o motivo exato da rejeição, 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 processo.

Como evitar bloquear o próprio acesso

Cada passo que altera a configuração do servidor precisa de um método de acesso alternativo que não dependa de SSH. Configure esse método enquanto o SSH ainda funciona, não depois de falhar.

1. Abra a consola do seu fornecedor através de serial ou VNC (virtual network computing) e confirme que consegue iniciar sessão por esse meio.
2. Certifique-se de que conhece uma palavra-passe local válida para uma conta com sudo. Se não tiver uma, reponha primeiro a palavra-passe do root através da consola do fornecedor.
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 nada 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 inícios de sessão, mas não afeta os existentes. Por isso, a sessão que está a utilizar não pode 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 efeito.

FAQ

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

Porque a chave está correta e o problema está noutro componente. Execute ssh -v e procure a linha Offering public key. Se a sua chave não aparecer, 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 aparecer 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 está a bloquear o utilizador. O log do servidor permite distinguir estes casos.

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

ssh -v host mostra uma linha debug1: Offering public key: por chave. Cada linha indica o ficheiro de origem e uma impressão digital SHA256. ssh-add -l lista as impressões digitais que o agente tem carregadas. ssh-keygen -lf ~/.ssh/id_ed25519.pub mostra a impressão digital de um único ficheiro de chave. ssh-keygen -y -f ~/.ssh/id_ed25519 mostra a chave pública que deriva realmente de uma chave privada. Para o login funcionar, a impressão digital da linha Offering também tem de aparecer em 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 atribua os três à 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 é agora 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 imediatamente, 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. Essa consola não passa pelo SSH. Inicie sessão com uma palavra-passe local. Execute sudo sshd -t para ver o erro de sintaxe e o respetivo número de linha. Reverta a alteração e reinicie o serviço. Depois, verifique sudo sshd -T para confirmar os valores em execução. 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 do root através da consola. Depois, corrija o ficheiro.