Resolver o erro SSH "Permission denied (publickey)"

A tentativa de ligação é interrompida ao fim de um segundo, não aparece qualquer pedido de palavra-passe, apenas uma única linha: Permission denied (publickey). Esta mensagem é tão incómoda precisamente porque não revela nada de propósito. O servidor SSH não diz a um potencial atacante se o utilizador existe, se a chave estava errada ou se o ficheiro não é legível. Só que exatamente a mesma reserva se aplica a si, quando está legitimamente à porta.

A boa notícia: as causas são poucas e conhecidas, podem ser percorridas por uma ordem fixa e, na maioria dos casos, resumem-se às permissões dos ficheiros. Este artigo percorre as causas pela ordem da sua frequência, mostra para cada uma o texto exato que aparece no log e explica como decidir, com ssh -vvv e em trinta segundos, se o problema está na sua máquina ou no servidor.

O que a mensagem significa exatamente

Os parênteses no fim não são um adorno, são a informação mais importante de toda a linha. Ali está indicado que métodos de autenticação o servidor ainda oferece depois da tentativa falhada:

Permission denied (publickey).
Permission denied (publickey,password).
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Se ali estiver apenas publickey, o início de sessão por palavra-passe está desativado no servidor. Se password constar da lista, um início de sessão por palavra-passe teria sido possível em princípio, apenas não foi tentado ou falhou também. A variante com gssapi é típica do AlmaLinux, do Rocky Linux e do RHEL, onde o suporte a Kerberos vem compilado de origem.

Importa distinguir das mensagens que se parecem com esta, mas descrevem um problema completamente diferente:

• Permission denied, please try again. sem parênteses é uma palavra-passe errada, não um problema de chave.
• Host key verification failed. diz respeito à chave do servidor no seu known_hosts, não à sua própria chave.
• Received disconnect from 203.0.113.7 port 22:2: Too many authentication failures significa que o seu agente ofereceu demasiadas chaves seguidas e o servidor interrompeu ao atingir o MaxAuthTries.
• Connection refused ou um timeout são temas de rede ou de firewall. Se andou antes a mexer numa firewall UFW ou no Fail2ban, comece por aí.

A bifurcação: ler o ssh -vvv corretamente

Antes de alterar seja o que for, peça ao cliente que lhe mostre todo o processo. Os três v são propositados, com um só v faltam as linhas decisivas:

ssh -vvv deploy@203.0.113.7

O resultado é longo, mas só procura quatro pontos. Primeiro, o nome de utilizador com que a ligação é realmente estabelecida:

debug1: Authenticating to 203.0.113.7:22 as 'deploy'

Segundo, que chaves o cliente sequer considera e, terceiro, qual delas envia de facto:

debug1: Will attempt key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk... agent
debug1: Offering public key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

E quarto, a mensagem de sucesso, que em caso de erro simplesmente não aparece:

debug1: Server accepts key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk...
debug1: Authenticated to 203.0.113.7 ([203.0.113.7]:22) using "publickey".

Daqui resulta a bifurcação que lhe poupa metade da procura do erro:

• Não aparece nenhum Offering public key com a sua chave. Então o problema está na sua máquina, a chave nunca chegou a ser enviada. Salte para a causa 3.
• Aparece Offering public key, mas logo a seguir surge de novo Authentications that can continue. Então o servidor viu a sua chave e recusou-a. São as causas 1, 2, 4, 5 e 6, todas do lado do servidor.
• Aparece send_pubkey_test: no mutual signature algorithm. Então a questão é o tipo de chave, salte para a causa 7.

Vale a pena olhar para mais duas linhas do resultado de depuração. debug3: no such identity: /home/tom/.ssh/id_rsa: No such file or directory é inofensivo, o cliente limita-se a experimentar todos os nomes padrão. Já Permissions 0644 for '/home/tom/.ssh/id_ed25519' are too open. é um achado a sério, porque nesse caso a sua chave privada fica ignorada.

O lado do servidor: sshd -T e os logs

O ssh -vvv mostra exclusivamente a perspetiva do cliente. A razão da recusa do servidor está apenas no log do servidor. Se ainda tiver uma sessão aberta ou conseguir entrar pela consola na área de cliente, comece por consultá-lo.

No Debian e no Ubuntu o serviço chama-se ssh, no AlmaLinux, no Rocky Linux e no RHEL chama-se sshd. É uma armadilha clássica ao copiar comandos:

journalctl -u ssh -n 50 --no-pager      # Debian, Ubuntu
journalctl -u sshd -n 50 --no-pager     # AlmaLinux, Rocky, RHEL

O clássico ficheiro de texto já não existe em todo o lado. O Ubuntu 22.04 e o 24.04 continuam a manter /var/log/auth.log na instalação de servidor, porque o rsyslog vem incluído. O Debian 12 e o Debian 13 já não instalam o rsyslog numa instalação mínima, ali o ficheiro simplesmente não existe e tudo vai parar ao journal. Na família Red Hat o ficheiro chama-se /var/log/secure. Quem quiser o ficheiro de texto de volta no Debian instala o rsyslog a posteriori, no Debian e no Ubuntu com apt-get install -y rsyslog, na família Red Hat com dnf install -y rsyslog.

O segundo comando no servidor é ainda mais importante, porque devolve a configuração que está realmente em vigor e resolve pelo caminho todos os ficheiros incluídos:

sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|strictmodes|permitrootlogin'

Se, em vez de uma configuração, o comando responder apenas com Missing privilege separation directory: /run/sshd e não devolver uma única linha, o que falta é simplesmente um diretório de tempo de execução. Isso acontece no Debian 11, no Debian 12, no Ubuntu 22.04 e no Ubuntu 24.04 logo a seguir à instalação do pacote, enquanto o serviço nunca tiver arrancado, e também dentro de containers. Em funcionamento normal, a unidade systemd cria o diretório sozinha através de RuntimeDirectory=sshd. Se a mensagem aparecer, resolve-se com um mkdir -p /run/sshd antes, e depois o sshd -T devolve corretamente permitrootlogin, pubkeyauthentication yes, strictmodes yes e authorizedkeysfile. O Debian 13 com OpenSSH 10 e toda a família Red Hat já não conhecem esta limitação. Tenha em atenção que a mensagem se perde dentro de um pipe: sshd -T | grep ... mostra então apenas um resultado vazio, e o verdadeiro código de retorno 255 desaparece no grep.

E se quiser mesmo ver o que o servidor pensa sem tocar no serviço em execução: arranque uma segunda instância em modo de depuração numa porta livre. Ela termina sozinha depois de uma ligação e não o consegue deixar de fora.

/usr/sbin/sshd -ddd -p 2222

A partir da sua máquina execute depois ssh -p 2222 deploy@203.0.113.7 e, no terminal do servidor, a recusa aparece em texto claro. Para isso, a porta tem naturalmente de estar aberta na firewall.

Causa 1: permissões e proprietário, de longe o caso mais frequente

O OpenSSH tem a opção StrictModes yes ativa por predefinição. O servidor recusa-se a ler uma chave de um ficheiro onde alguém além do próprio utilizador possa escrever. Não é maldade, evita que outro utilizador escreva simplesmente a sua própria chave no seu authorized_keys.

O estado correto está definido de forma restrita:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 750 ~
chown -R "$(id -un):$(id -gn)" ~/.ssh

A verificação cabe numa única linha:

stat -c "%a %U %G %n" ~ ~/.ssh ~/.ssh/authorized_keys

Espera-se 750 ou 700 para o diretório pessoal, 700 para .ssh e 600 para authorized_keys, e nas três linhas o seu próprio nome de utilizador. O ponto decisivo: o diretório pessoal não pode ser gravável pelo grupo nem pelos outros, ou seja, 770 ou 777 já bastam para tudo falhar.

Há um número que não deve interpretar como erro: no AlmaLinux, no Rocky Linux e no Oracle Linux, /root tem as permissões 550 e não 700 como no Debian e no Ubuntu. O stat -c mostra isso corretamente e está tudo bem assim. Para o StrictModes só conta que grupo e outros não tenham direito de escrita, e é exatamente isso que 550 garante. Quem acrescentar aqui um chmod 700 /root não reparou o início de sessão, apenas tapou ainda mais a causa.

No log do servidor fica então bem explícito:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh
Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys
error: Could not open authorized keys '/home/deploy/.ssh/authorized_keys': Permission denied

Dois detalhes que outros guias costumam deixar de fora. Primeiro, o proprietário: se criou o ficheiro com sudo nano ~/.ssh/authorized_keys, ele pertence ao root e não ao utilizador, e o início de sessão falha apesar de permissões 600 perfeitas. Segundo, o sshd verifica todo o caminho para cima. Se o diretório pessoal não estiver em /home, mas por exemplo em /srv/clientes/deploy, então /srv e /srv/clientes também têm de pertencer ao root ou ao utilizador e não podem ser graváveis pelo grupo nem pelos outros.

Causa 2: o nome de utilizador errado

Um utilizador que não existe produz exatamente a mesma mensagem que uma chave errada, porque o servidor não revela de propósito qual dos dois casos se aplica. No log, a diferença vê-se de imediato:

Invalid user deply from 203.0.113.7 port 51234

O motivo mais frequente é a chave estar em /root/.ssh/authorized_keys enquanto inicia sessão como utilizador normal, ou o contrário. Em imagens cloud prontas, o início de sessão como root está muitas vezes bloqueado e existe em vez disso um utilizador preparado, conforme a distribuição debian, ubuntu, almalinux ou rocky. Já nas imagens padrão de um servidor root KernelHost, inicia sessão diretamente como root.

Verifique além disso se o seu ~/.ssh/config não lhe está a impor outro utilizador. O comando seguinte não estabelece qualquer ligação, mostra apenas que definições se aplicam realmente a este destino:

ssh -G deploy@203.0.113.7

No resultado interessam user, hostname, port e a lista de entradas identityfile.

Causa 3: a chave nem sequer é oferecida

Se no ssh -vvv não aparecer nenhum Offering public key com a sua chave, o servidor nunca chegou a ter hipótese. Para isso há quatro razões típicas.

A chave tem um nome próprio

Automaticamente, o OpenSSH só experimenta os nomes padrão id_ed25519, id_ecdsa e id_rsa. Uma chave chamada id_producao só é usada se a indicar explicitamente:

ssh -i ~/.ssh/id_producao -o IdentitiesOnly=yes deploy@203.0.113.7

IdentitiesOnly=yes não é aqui um acessório. Sem esta opção, o ssh oferece adicionalmente todas as chaves do agente e, com demasiadas tentativas, o servidor interrompe com Too many authentication failures antes de sequer chegar a vez da chave certa.

O agente não tem a chave

ssh-add -l

Se o comando responder com The agent has no identities. ou Could not open a connection to your authentication agent., carregue a chave com ssh-add ~/.ssh/id_ed25519.

Permissões da chave privada

A chave privada tem de ter 600, caso contrário o cliente recusa o serviço. No Windows o chmod não tem efeito, ali trabalha-se com ACLs:

icacls %USERPROFILE%\.ssh\id_ed25519 /inheritance:r /grant:r "%USERNAME%":R

O ficheiro authorized_keys está corrompido

Uma chave pública ocupa exatamente uma linha. Ao copiar através de editores, sistemas de tickets ou janelas de chat, aparece com frequência uma quebra de linha a meio do bloco Base64, e a partir daí já nada encaixa. Faça a contagem:

grep -c '^ssh-' ~/.ssh/authorized_keys
awk '{print NR": "NF" campos, tipo "$1}' ~/.ssh/authorized_keys

Cada linha tem de começar por ssh-ed25519, ssh-rsa ou ecdsa-sha2- e ser composta por dois a três campos. O número de linhas tem de corresponder ao número de chaves. Um segundo clássico é ter sido colada por engano a chave privada em vez da pública, algo que se reconhece por BEGIN OPENSSH PRIVATE KEY. E uma chave em formato PuTTY (.ppk) não funciona assim, tem primeiro de ser exportada para OpenSSH.

Se a chave privada e a pública formam mesmo um par, esclarece-o uma comparação de impressões digitais:

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh-keygen -lf ~/.ssh/authorized_keys

O mesmo valor SHA256 tem de aparecer nos dois resultados. Como fica tudo isto montado de forma correta, explicamos no nosso artigo sobre proteger o SSH e configurar o início de sessão por chave.

Causa 4: o PubkeyAuthentication está desligado

Mais raro, mas nesse caso muito claro. Não verifique o ficheiro de configuração, verifique o resultado:

sshd -T | grep -i pubkeyauthentication

Aqui espreita uma armadilha que custa muitas horas. O Debian a partir da versão 12 e o Ubuntu a partir do 22.04 têm logo no topo de /etc/ssh/sshd_config a linha Include /etc/ssh/sshd_config.d/*.conf. No sshd vale a regra: para cada palavra-chave conta o valor encontrado em primeiro lugar. Como a inclusão está no início, qualquer pormenor vindo de sshd_config.d ganha ao ficheiro principal, independentemente do que esteja mais abaixo. Se a sua alteração não produzir efeito, é ali que deve procurar:

grep -rniE 'pubkeyauthentication|authorizedkeysfile|allowusers|allowgroups' /etc/ssh/

O segundo ponto desta categoria é o AuthorizedKeysFile. O padrão são .ssh/authorized_keys e .ssh/authorized_keys2. Alguns scripts de hardening colocam o caminho em algo como /etc/ssh/authorized_keys/%u. A partir daí, o seu ficheiro no diretório pessoal é completamente ignorado, sem qualquer mensagem de erro. Também isso é mostrado pelo sshd -T.

Causa 5: AllowUsers, AllowGroups e Match estão a atuar

Estas diretivas cortam grupos inteiros de utilizadores, e fazem-no antes de a chave sequer ser verificada. O texto que aparece no log:

User root from 203.0.113.7 not allowed because not listed in AllowUsers
User deploy from 203.0.113.7 not allowed because none of user's groups are listed in AllowGroups
User root from 203.0.113.7 not allowed because "PermitRootLogin no"

Guarde a ordem de precedência: DenyUsers vence AllowUsers e, assim que AllowUsers estiver definido, todos os utilizadores não mencionados ficam de fora. Com AllowGroups, a pertença ao grupo tem de estar certa, algo que verifica com id deploy.

No PermitRootLogin a distinção é importante: prohibit-password permite o início de sessão como root com chave. Só no bloqueia o root por completo. No resultado de sshd -T não espere, no entanto, a palavra prohibit-password: ali aparece o nome mais antigo e equivalente without-password. E o valor por predefinição não é de todo igual em todo o lado, o que gera confusão com regularidade ao comparar dois servidores:

No AlmaLinux, portanto, o root também pode entrar com palavra-passe, nos restantes sistemas indicados não. Quem mudar um serviço de AlmaLinux para Debian e até aí iniciava sessão como root com palavra-passe, vai aterrar exatamente em Permission denied (publickey).

Se a regra estiver dentro de um bloco Match, ajuda a opção que avalia a configuração para um caso concreto:

sshd -T -C user=deploy,host=client.example.com,addr=203.0.113.7 | grep -Ei 'pubkeyauth|allowusers|permitrootlogin'

É a forma mais fiável de ver o que se aplica exatamente a este utilizador vindo exatamente deste endereço IP.

Causa 6: SELinux no AlmaLinux, Rocky e RHEL

Na família Red Hat, o SELinux corre por predefinição no modo Enforcing, no Debian e no Ubuntu não desempenha qualquer papel. O processo sshd só pode ler o authorized_keys se o ficheiro tiver o contexto ssh_home_t. É o que acontece quando foi criado normalmente no diretório pessoal. Não é o que acontece se o trouxe de /tmp com mv ou se criou o diretório pessoal à mão, porque o mv leva o contexto antigo consigo.

getenforce
ls -Z ~/.ssh

O correto é uma entrada terminada em ssh_home_t. Se ali estiver user_tmp_t ou user_home_t, a causa está encontrada. A reparação:

restorecon -R -v ~/.ssh

Este passo aplica-se exclusivamente à família Red Hat. No Debian e no Ubuntu não existe uma configuração SELinux padrão, ali a shell responde com restorecon: command not found, e isso não é um erro, é simplesmente não aplicável. Mas também no AlmaLinux e no Rocky Linux o comando falta numa instalação enxuta, porque o respetivo pacote não vem definido. Nesse caso, instale-o antes:

dnf install -y policycoreutils

As provas encontram-se no log de auditoria, ali a recusa aparece em texto claro:

ausearch -m avc -ts recent

Se os diretórios pessoais estiverem num local invulgar, o restorecon sozinho não chega, porque o SELinux nem sequer conhece esse caminho como diretório pessoal. Nesse caso, registe a equivalência uma única vez e reponha os contextos a seguir:

semanage fcontext -a -e /home /srv/clientes
restorecon -R -v /srv/clientes

O semanage está no pacote policycoreutils-python-utils. Não desligue o SELinux para pôr o início de sessão a funcionar, isso resolve um problema de dois comandos à custa de uma perda de segurança em todo o sistema.

Causa 7: servidor antigo, tipo de chave errado

Desde o OpenSSH 8.8 que o cliente recusa assinaturas RSA com SHA-1. Já o Ubuntu 22.04 é afetado e o Debian 13 traz entretanto o OpenSSH 10. Se, a partir de um sistema assim tão atual, quiser chegar a um servidor muito antigo que só domina o velho ssh-rsa, vê no resultado de depuração:

debug1: send_pubkey_test: no mutual signature algorithm

Não é um problema de permissões, a sua chave está perfeitamente bem. Para um acesso pontual ajuda:

ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa deploy@203.0.113.7

De forma permanente, isto pertence ao ~/.ssh/config por baixo de uma entrada Host, para que afete apenas este servidor. Em clientes muito antigos a opção ainda se chama PubkeyAcceptedKeyTypes. A verdadeira solução é atualizar o servidor antigo, porque a partir do OpenSSH 7.2 também ele domina as variantes SHA-2, e a sua chave RSA existente continua a funcionar sem alterações. Muda apenas o método de assinatura.

O caso contrário também existe. Uma chave ed25519 precisa de pelo menos OpenSSH 6.5 dos dois lados, tokens de hardware do tipo ed25519-sk de pelo menos 8.2. E o DSA é história: desde o OpenSSH 10.0 que ssh-dss foi removido por completo, e chaves antigas desse género já não funcionam de todo contra o Debian 13. Os tipos que o seu cliente conhece são mostrados por:

ssh -Q key

Se o ssh faltar por completo num AlmaLinux, Rocky Linux ou RHEL acabado de instalar, a razão é uma armadilha nos nomes dos pacotes: o dnf install openssh-server traz apenas o serviço, não as ferramentas de cliente. Sem elas faltam ssh, ssh-add e, com eles, também ssh -Q e ssh -G. A instalação posterior faz-se com s no plural, ao contrário do pacote Debian openssh-client:

dnf install -y openssh-clients

No AlmaLinux, no Rocky e no RHEL 9 acresce um segundo nível. Ali as políticas criptográficas de todo o sistema também determinam o que é permitido, independentemente da configuração do sshd:

update-crypto-policies --show

Também esta ferramenta é exclusiva do lado Red Hat, no Debian e no Ubuntu não existe. E mesmo no Oracle Linux 9 falta na instalação mínima, ali o dnf install -y crypto-policies-scripts trata disso e, a seguir, sai DEFAULT como esperado. Se ali estiver DEFAULT, as assinaturas SHA-1 já estão bloqueadas em todo o sistema. O update-crypto-policies --set LEGACY resolve isso, mas enfraquece a máquina inteira e deve ser quando muito uma solução de transição para uma migração.

Quando ficou fechado de fora

O momento perigoso não é o erro em si, é a reparação no sshd_config. Três regras que tornam o bloqueio praticamente impossível:

1. Deixe uma segunda sessão aberta. Reiniciar o sshd não corta as ligações existentes. Enquanto um terminal se mantiver aberto, pode reverter qualquer alteração.
2. Verifique a sintaxe antes de cada reinício. O sshd -t indica o número da linha em caso de erro e cala-se quando está tudo certo. Caso contrário, um simples erro de escrita na configuração impede o arranque do serviço, e depois já ninguém entra. Se em vez disso surgir Missing privilege separation directory: /run/sshd, a sua configuração está em ordem e falta apenas o diretório de tempo de execução, ver acima.
3. Teste a partir da segunda sessão, antes de fechar a primeira.

No reinício, os sistemas diferem. No Debian e no Ubuntu a unidade chama-se ssh, na família Red Hat sshd. Desde o Ubuntu 22.10 e no Debian 13, o SSH é adicionalmente arrancado por ativação de socket: a configuração de sshd_config continua a valer, mas uma indicação Port alterada só faz efeito depois de o ssh.socket ter sido igualmente reiniciado.

sshd -t
systemctl restart ssh          # Debian, Ubuntu
systemctl restart ssh.socket   # adicionalmente, se a porta foi alterada
systemctl restart sshd         # AlmaLinux, Rocky, RHEL

Se mesmo assim acontecer, precisa de um caminho que contorne o SSH. Num servidor root KernelHost, abre a consola VNC na área de cliente e inicia ali sessão com a palavra-passe de root, sem qualquer serviço de rede pelo meio. Se isso não levar a lado nenhum, por exemplo porque o sshd já nem arranca, ajuda o sistema de recuperação: arranca num ambiente de emergência, monta o sistema de ficheiros da máquina e corrige o authorized_keys e as permissões diretamente no disco. Lembre-se de verificar os proprietários depois de montar, porque no sistema de recuperação é root e, de outro modo, cria ficheiros com o proprietário errado.

Como reconhece que funciona mesmo

O facto de um início de sessão resultar não significa ainda que tenha corrido pela chave. Enquanto o início de sessão por palavra-passe estiver ativo, o servidor pode deixá-lo cair silenciosamente nesse método. O teste honesto exclui qualquer outro método:

ssh -o BatchMode=yes -o PreferredAuthentications=publickey deploy@203.0.113.7 'id -un; hostname'

BatchMode=yes suprime qualquer pergunta interativa. Se o seu nome de utilizador e o hostname vierem de volta e o echo $? devolver a seguir um 0, então trabalhou exclusivamente a chave.

A segunda prova está no log do servidor e indica até a impressão digital da chave utilizada:

Accepted publickey for deploy from 203.0.113.7 port 51234 ssh2: ED25519 SHA256:8Qk...

Compare este valor SHA256 com o resultado de ssh-keygen -lf ~/.ssh/id_ed25519.pub. Se os dois coincidirem, sabe não só que o início de sessão funciona, mas também qual foi a chave usada. Isso é relevante quando há várias chaves em jogo e quer retirar uma delas.

A ordem por que deve avançar

Se não tem tempo para teoria, percorra esta lista de cima para baixo. Está ordenada por frequência, não por elegância.

1. Arrancar o ssh -vvv e apurar se aparece Offering public key. Isso divide o problema entre cliente e servidor.
2. Verificar as permissões: 700 em ~/.ssh, 600 em authorized_keys, diretório pessoal não gravável pelo grupo, tudo na posse do utilizador.
3. Verificar o nome de utilizador, na dúvida consultar o ssh -G e procurar Invalid user no log.
4. Comparar as impressões digitais da chave privada e do authorized_keys, controlar o número de linhas do ficheiro.
5. Avaliar o sshd -T: pubkeyauthentication, authorizedkeysfile, strictmodes, permitrootlogin.
6. Verificar AllowUsers, AllowGroups, DenyUsers e blocos Match, incluindo o diretório sshd_config.d.
7. Na família Red Hat, ls -Z ~/.ssh e, se necessário, restorecon -R -v ~/.ssh.
8. Só com contrapartes muito antigas: alargar o algoritmo de assinatura com PubkeyAcceptedAlgorithms=+ssh-rsa.

O mais tardar aqui, a causa está encontrada. Se depois quiser montar o acesso de novo e de forma limpa, a introdução à ligação por SSH e a checklist para um novo servidor root são os pontos de continuação certos.