Un error SSH completo suele verse así:

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

Estos significan cosas distintas.

Si solo copias la última línea Permission denied y la buscas, es fácil desviarte. Primero pega el error completo, especialmente los métodos de autenticación entre paréntesis.

Sugiero añadir primero -v para ver registros detallados:

ssh -v root@your_server_ip

Si hay demasiada información, usa el más detallado:

ssh -vvv root@your_server_ip

Fíjate en estas líneas:

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

Esto indica que el cliente sí tomó la clave e intentó usarla, pero el servidor no la aceptó.

No todos los sistemas usan root para el inicio de sesión en VPS.

Los usuarios predeterminados comunes son más o menos:

Una vez ayudé a un amigo a revisarlo. Él seguía usando:

ssh [email protected]

Pero esa máquina era una imagen cloud de Ubuntu, que por defecto solo permite:

ssh [email protected]

La contraseña, la clave y el puerto estaban bien; simplemente el nombre de usuario era incorrecto.

Al diagnosticar, haz primero tres cosas:

1. Revisa el correo de activación del VPS
2. Revisa las instrucciones de inicio de sesión en la consola en la nube
3. Revisa si especificaste un usuario SSH al crear la instancia

Si no estás seguro, prueba primero estos:

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

No reinicies el sistema de inmediato.

Mucha gente tiene varias claves SSH en local:

ls -la ~/.ssh

Puede que veas:

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

El cliente SSH no necesariamente elige automáticamente la que quieres. Lo más fiable es especificarla explícitamente:

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

Si ya escribiste ~/.ssh/config, revisa también si la coincidencia de Host es incorrecta:

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

Luego inicia sesión:

ssh my-vps

Aquí IdentitiesOnly yes es muy útil. Hace que el cliente use solo la clave que especificas, evitando que el agente local meta un montón de claves irrelevantes y el servidor rechace antes de tiempo.

Si ves un aviso como:

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

No es el servidor rechazándote; es que tu cliente SSH local no está usando esta clave privada en absoluto.

Corrige los permisos:

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

Si es un archivo de clave pública:

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

Vuelve a intentarlo:

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

Los usuarios de Windows que usan WSL también deben cambiar los permisos dentro de WSL. Cuando la clave privada está en una unidad montada de Windows, el modelo de permisos a veces es molesto; se recomienda copiarla directamente al directorio ~/.ssh/ de WSL.

Si aún puedes entrar mediante VNC de la consola, modo rescate o Web Shell del proveedor cloud, revisa los permisos del lado del servidor:

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

Para root, normalmente debería ser:

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

Para un usuario normal, por ejemplo ubuntu:

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

Una trampa fácil de pasar por alto: escribiste la clave con root en el directorio de un usuario normal, así que el propietario sigue siendo root.

Por ejemplo:

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

Pero inicias sesión como ubuntu, entonces está mal. Cámbialo a:

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

authorized_keys debe contener la clave pública, no la privada.

Una clave pública suele verse así:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... yourname@machine

O:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... yourname@machine

Una clave privada suele verse así; nunca la pongas ahí:

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

Si tienes la clave privada en local, puedes generar la clave pública correspondiente así:

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

Luego añade la salida al archivo del usuario correspondiente en el servidor:

~/.ssh/authorized_keys

Al añadir, usa:

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

No sobrescribas el archivo original a menos que estés seguro de que no hay otras claves aún en uso.

Si has cambiado la configuración de seguridad de SSH, fíjate en:

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

Hay varios problemas comunes.

PasswordAuthentication no

PasswordAuthentication yes

sudo sshd -t

sudo systemctl reload ssh

sudo systemctl reload sshd

PermitRootLogin no

PermitRootLogin prohibit-password

AllowUsers deploy

Si puedes entrar a la consola, mira directamente los registros de SSH.

Ubuntu / Debian común:

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

Rocky / AlmaLinux / CentOS común:

sudo tail -n 100 /var/log/secure

systemd también sirve:

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

Verás una razón más clara, por ejemplo:

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

Esto es mucho más eficaz que probar a ciegas en local.

Si has introducido mal los datos muchas veces seguidas, puede que no sea un problema de configuración de autenticación, sino que tu IP esté bloqueada.

Revisa primero Fail2Ban:

sudo fail2ban-client status
sudo fail2ban-client status sshd

Si tu IP está en la lista de bloqueo:

sudo fail2ban-client set sshd unbanip your_home_ip

Si no puedes entrar en absoluto, solo puedes gestionarlo desde la consola cloud, VNC o modo rescate.

También revisa el firewall del proveedor cloud:

• Si el grupo de seguridad permite el puerto 22
• Si solo se permite iniciar sesión desde una IP concreta
• Si la IP de tu banda ancha doméstica ha cambiado
• Si cambiaste el puerto SSH a algo como 2222 o 22022

Si el puerto se cambió, el comando debe llevar -p:

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

Ojo con las mayúsculas: en el comando SSH el indicador de puerto es minúscula -p, mientras que en scp el puerto es mayúscula -P.

Si SSH ya no permite iniciar sesión en absoluto, no te apresures a reinstalar. Sigue este orden:

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

lsblk

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

Si solo es:

• Nombre de usuario incorrecto
• Permisos de clave incorrectos
• authorized_keys incorrecto
• Configuración de sshd incorrecta

Basta con corregirlo; no hace falta reinstalar.

Pero si ves estas señales, ten cuidado:

• Aparecen claves públicas desconocidas en authorized_keys
• Se añadieron usuarios desconocidos
• Hay muchos registros de inicio de sesión exitoso en los registros de SSH
• Se modificó /etc/sudoers
• Hay tareas desconocidas en crontab / systemd
• Se sospecha que la máquina se usa para escanear puertos, enviar paquetes o minar

Esto ya no es solo un problema de inicio de sesión SSH; hay que tratarlo como un incidente de intrusión. Puedes leer esto: Lista de actuación de 24 horas tras la intrusión de un VPS.

Tras arreglarlo, sugiero organizarlo en este estado:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password

Luego configura un usuario sudo normal:

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

Escribe en local en ~/.ssh/config:

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

A partir de entonces, iniciar sesión es una sola línea:

ssh my-vps

No escribas a mano una cadena larga cada vez, ni dejes el inicio de sesión de root con contraseña habilitado a largo plazo.

Cuando te encuentres con Permission denied, sigue este orden:

1. ssh -v user@ip para ver el proceso completo de autenticación
2. Confirma si el nombre de usuario es root, ubuntu, debian o el usuario indicado por el proveedor
3. Usa ssh -i key user@ip para especificar explícitamente la clave privada
4. Corrige los permisos de la clave privada local: chmod 600 key
5. Revisa los permisos de .ssh y authorized_keys en el servidor
6. Confirma que authorized_keys contiene la clave pública, no la privada
7. Revisa PasswordAuthentication, PermitRootLogin, AllowUsers
8. Mira /var/log/auth.log, /var/log/secure o journalctl
9. Comprueba si Fail2Ban ha bloqueado tu IP
10. Revisa el firewall cloud, el grupo de seguridad y el puerto SSH
11. Si aún no puedes entrar, usa VNC / modo rescate para corregir la configuración

Si tu síntoma no es Permission denied sino tiempo de espera de conexión, puerto inaccesible o servicio sin respuesta, la dirección del diagnóstico es distinta. Puedes continuar con: El servicio del VPS está iniciado pero no es accesible desde internet y Qué hacer si Fail2Ban bloquea un VPS por error.

Por último, un consejo práctico: antes de cambiar la configuración de SSH, abre primero dos terminales. Mantén una sesión SSH existente sin desconectar y usa la otra para probar una nueva conexión. Cuando confirmes que la nueva conexión funciona, cierra la ventana antigua. Este pequeño hábito puede ahorrarte muchos rescates de la máquina.