Um erro SSH completo costuma ser assim:

Permission denied (publickey).
Permission denied (publickey,password).
Permission denied, please try again.

Esses significam coisas diferentes.

Se você copiar só a última linha Permission denied e pesquisar, é fácil se perder. Primeiro cole o erro completo, especialmente os métodos de autenticação entre parênteses.

Sugiro adicionar primeiro -v para ver logs detalhados:

ssh -v root@your_server_ip

Se houver informação demais, use o mais detalhado:

ssh -vvv root@your_server_ip

Preste atenção nestas linhas:

Offering public key: /Users/you/.ssh/id_ed25519
Authentications that can continue: publickey
No more authentication methods to try.

Isso mostra que o cliente realmente pegou a chave e tentou usá-la, mas o servidor não aceitou.

Nem todo sistema usa root para login no VPS.

Os usuários padrão comuns são mais ou menos:

Uma vez ajudei um amigo a verificar. Ele insistia em usar:

ssh [email protected]

Mas aquela máquina era uma imagem cloud do Ubuntu, que por padrão só permite:

ssh [email protected]

Senha, chave e porta estavam certas; era simplesmente o nome de usuário errado.

Ao diagnosticar, faça três coisas primeiro:

1. Veja o e-mail de ativação do VPS
2. Veja as instruções de login no console da nuvem
3. Veja se você especificou um usuário SSH ao criar a instância

Se não tiver certeza, tente primeiro estes:

ssh root@your_server_ip
ssh ubuntu@your_server_ip
ssh debian@your_server_ip

Não reinicie o sistema logo de cara.

Muita gente tem várias chaves SSH no local:

ls -la ~/.ssh

Pode aparecer:

id_rsa
id_rsa.pub
id_ed25519
id_ed25519.pub
my-vps.pem
company-key.pem

O cliente SSH não necessariamente escolhe automaticamente a que você quer. A forma mais confiável é especificar explicitamente:

ssh -i ~/.ssh/my-vps.pem root@your_server_ip

Se você já escreveu ~/.ssh/config, verifique também se a correspondência de Host está errada:

Host my-vps
  HostName your_server_ip
  User root
  IdentityFile ~/.ssh/my-vps.pem
  IdentitiesOnly yes

Depois faça login:

ssh my-vps

Aqui IdentitiesOnly yes é muito útil. Ele faz o cliente usar só a chave que você especificou, evitando que o agente local empurre um monte de chaves irrelevantes e o servidor rejeite antes da hora.

Se você vir um aviso como:

WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0644 for 'my-vps.pem' are too open.
This private key will be ignored.

Não é o servidor te rejeitando; é o seu cliente SSH local que não está usando essa chave privada de jeito nenhum.

Corrija as permissões:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/my-vps.pem

Se for um arquivo de chave pública:

chmod 644 ~/.ssh/my-vps.pem.pub

Tente de novo:

ssh -i ~/.ssh/my-vps.pem root@your_server_ip

Usuários de Windows que usam WSL também precisam alterar as permissões dentro do WSL. Quando a chave privada está em uma unidade montada do Windows, o modelo de permissões às vezes é chato; recomendo copiar direto para o diretório ~/.ssh/ do WSL.

Se você ainda consegue entrar pelo VNC do console, modo de resgate ou Web Shell do provedor de nuvem, verifique as permissões do lado do servidor:

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

Para root, normalmente deve ser:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
chown -R root:root /root/.ssh

Para um usuário comum, por exemplo ubuntu:

chmod 700 /home/ubuntu/.ssh
chmod 600 /home/ubuntu/.ssh/authorized_keys
chown -R ubuntu:ubuntu /home/ubuntu/.ssh

Uma armadilha fácil de passar batido: você usou root para escrever a chave no diretório de um usuário comum, então o owner continua sendo root.

Por exemplo:

-rw------- 1 root root 399 authorized_keys

Mas você faz login como ubuntu, então está errado. Altere para:

chown ubuntu:ubuntu /home/ubuntu/.ssh/authorized_keys

authorized_keys deve conter a chave pública, não a privada.

Uma chave pública costuma ser assim:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... yourname@machine

Ou:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... yourname@machine

Uma chave privada costuma ser assim; nunca a coloque aí:

-----BEGIN OPENSSH PRIVATE KEY-----
...
-----END OPENSSH PRIVATE KEY-----

Se você tem a chave privada no local, pode gerar a chave pública correspondente assim:

ssh-keygen -y -f ~/.ssh/my-vps.pem

Depois acrescente a saída ao arquivo do usuário correspondente no servidor:

~/.ssh/authorized_keys

Ao acrescentar, use:

echo 'ssh-ed25519 AAAA...' >> ~/.ssh/authorized_keys

Não sobrescreva o arquivo original, a menos que tenha certeza de que não há outras chaves ainda em uso.

Se você alterou a configuração de segurança do SSH, foque em:

sudo sshd -t
sudo grep -E '^(PasswordAuthentication|PubkeyAuthentication|PermitRootLogin|AuthorizedKeysFile|AllowUsers|DenyUsers)' /etc/ssh/sshd_config

Há alguns problemas comuns.

PasswordAuthentication no

PasswordAuthentication yes

sudo sshd -t

sudo systemctl reload ssh

sudo systemctl reload sshd

PermitRootLogin no

PermitRootLogin prohibit-password

AllowUsers deploy

Se você consegue entrar no console, veja diretamente os logs do SSH.

Ubuntu / Debian comum:

sudo tail -n 100 /var/log/auth.log

Rocky / AlmaLinux / CentOS comum:

sudo tail -n 100 /var/log/secure

systemd também funciona:

sudo journalctl -u ssh -n 100 --no-pager
sudo journalctl -u sshd -n 100 --no-pager

Você verá um motivo mais claro, por exemplo:

Failed publickey for root from 1.2.3.4 port 52110 ssh2
Authentication refused: bad ownership or modes for directory /root/.ssh
User ubuntu not allowed because not listed in AllowUsers
Failed password for invalid user admin from 1.2.3.4

Isso é bem mais eficaz do que testar às cegas no local.

Se você errou muitas vezes seguidas, pode não ser problema de configuração de autenticação, mas do seu IP ter sido bloqueado.

Verifique primeiro o Fail2Ban:

sudo fail2ban-client status
sudo fail2ban-client status sshd

Se o seu IP estiver na lista de bloqueio:

sudo fail2ban-client set sshd unbanip your_home_ip

Se você não consegue entrar de jeito nenhum, só dá para resolver pelo console da nuvem, VNC ou modo de resgate.

O firewall do provedor de nuvem também precisa ser verificado:

• Se o security group libera a porta 22
• Se só permite login de um IP específico
• Se o IP da sua banda larga residencial mudou
• Se você alterou a porta SSH para algo como 2222 ou 22022

Se a porta foi alterada, o comando precisa levar -p:

ssh -p 2222 -i ~/.ssh/my-vps.pem root@your_server_ip

Atenção ao maiúsculo/minúsculo: no comando SSH o indicador de porta é minúsculo -p, enquanto em scp a porta é maiúscula -P.

Se o SSH já não permite login de forma alguma, não corra para reinstalar. Siga esta ordem:

mkdir /mnt/sysroot
mount /dev/vda1 /mnt/sysroot

lsblk

cat /mnt/sysroot/etc/ssh/sshd_config
ls -la /mnt/sysroot/root/.ssh

Se for só:

• Nome de usuário errado
• Permissão de chave errada
• authorized_keys errado
• Configuração do sshd errada

Basta corrigir; não precisa reinstalar.

Mas se você vir estes sinais, tenha cuidado:

• Aparecem chaves públicas desconhecidas em authorized_keys
• Foram adicionados usuários desconhecidos
• Há muitos registros de login bem-sucedido nos logs do SSH
• /etc/sudoers foi alterado
• Há tarefas desconhecidas no crontab / systemd
• A máquina é suspeita de estar sendo usada para escanear portas, enviar pacotes ou minerar

Isso já não é só um problema de login SSH; deve ser tratado como incidente de invasão. Você pode ler este artigo: Checklist de 24 horas após um VPS ser invadido.

Depois de corrigir, sugiro organizar neste estado:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password

Depois configure um usuário sudo comum:

adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Escreva no local em ~/.ssh/config:

Host my-vps
  HostName your_server_ip
  User deploy
  Port 22
  IdentityFile ~/.ssh/my-vps.pem
  IdentitiesOnly yes

A partir daí, o login é uma linha só:

ssh my-vps

Não fique digitando uma sequência longa toda vez, nem deixe o login de root por senha habilitado a longo prazo.

Quando encontrar Permission denied, siga esta ordem:

1. ssh -v user@ip para ver o processo completo de autenticação
2. Confirme se o nome de usuário é root, ubuntu, debian ou o usuário indicado pelo provedor
3. Use ssh -i key user@ip para especificar explicitamente a chave privada
4. Corrija as permissões da chave privada local: chmod 600 key
5. Verifique as permissões de .ssh e authorized_keys no servidor
6. Confirme que authorized_keys contém a chave pública, não a privada
7. Verifique PasswordAuthentication, PermitRootLogin, AllowUsers
8. Veja /var/log/auth.log, /var/log/secure ou journalctl
9. Verifique se o Fail2Ban bloqueou o seu IP
10. Verifique o firewall da nuvem, o security group e a porta SSH
11. Se ainda não conseguir entrar, use VNC / modo de resgate para corrigir a configuração

Se o seu sintoma não for Permission denied, mas timeout de conexão, porta inacessível ou serviço sem resposta, a direção do diagnóstico é diferente. Você pode continuar com: O serviço do VPS iniciou mas não é acessível pela internet e O que fazer quando o Fail2Ban bloqueia um VPS por engano.

Por fim, uma dica prática: antes de alterar a configuração do SSH, abra dois terminais. Mantenha uma sessão SSH existente sem desconectar e use a outra para testar uma nova conexão. Quando confirmar que a nova conexão funciona, feche a janela antiga. Esse pequeno hábito pode evitar muitos resgates da máquina.