Cómo diagnosticar errores SSH en un VPS Ubuntu
El mensaje de SSH indica por dónde empezar: red, servicio, autenticación o identidad del servidor. Conserva cualquier sesión que funcione y revisa una causa cada vez antes de cambiar reglas, claves o configuración.
En esta guía
Captura un fallo sin perder el acceso existente
Localiza la consola de recuperación del proveedor. Los comandos de cliente se ejecutan en tu ordenador con Linux, macOS o WSL; los de servidor, mediante una sesión existente o la consola autenticada.
Sustituye la IP de documentación, usuario, puerto y ruta de clave por los que utilizas. Primero muestra la configuración efectiva y después intenta una conexión nueva:
ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Revisa hostname, user, port, identityfile y cualquier proxy. La segunda orden evita reutilizar una conexión anterior. Registra hora y error final. Verifica cualquier huella nueva mediante el apartado de identidad. Oculta datos privados antes de compartir el diagnóstico y nunca compartas claves privadas.
Elige la comprobación según el mensaje
Desplaza la tabla para ver todas las columnas →
| Mensaje o fase | Qué indica | Siguiente comprobación |
|---|---|---|
| Connection timed out antes de establecer la conexión | No se completó la conexión TCP | Dirección, ruta, cortafuegos y estado del proveedor |
| Connection refused | Rechazo activo en esa dirección y puerto | Puerto previsto, servicio escuchando y reglas de rechazo |
| Permission denied (publickey) | Se llegó a autenticación, pero no se aceptó la credencial | Usuario, clave ofrecida y política del servidor |
| REMOTE HOST IDENTIFICATION HAS CHANGED | La identidad presentada difiere de la guardada | Verificación de la clave del servidor desde una consola de confianza |
El mensaje reduce las posibilidades, pero no demuestra una causa única. Si aparece Connection established antes de agotarse el tiempo, investiga el intercambio SSH y los registros; no concluyas que todos los paquetes están bloqueados.
Tiempo de espera: sigue la ruta de red
Comprueba que el VPS está encendido y que la IP pública sigue asociada a la instancia correcta. Una dirección privada no es accesible directamente desde Internet sin VPN u otra ruta preparada.
Revisa ruta, puerta de enlace y reglas asociadas al proveedor. En una regla /32 de SSH debe figurar la IP pública actual de tu equipo. El cortafuegos del servidor es otra capa: consulta su estado desde la consola y conserva las reglas esenciales de la imagen.
No abras todos los puertos ni sustituyas el cortafuegos para probar. Contrasta el puerto efectivo del cliente con el que escucha el servidor.
Conexión rechazada: comprueba el servicio
Desde el servidor mediante acceso existente o consola, consulta unidades, puertos y registros:
systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pagerUbuntu puede activar SSH mediante socket. Comprueba ssh.socket además de ssh.service antes de concluir que falta el servicio. La salida de ss indica la dirección y puerto de escucha; sshd -t valida la configuración, pero no la cambia.
Investiga el error concreto antes de reiniciar unidades. Si necesitas modificar un archivo, guarda su versión anterior, valida la sintaxis y mantén una vía de recuperación.
Clave rechazada: confirma usuario e identidad ofrecida
En tu ordenador fuerza solo la clave elegida para este intento:
ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Busca qué clave se ofrece en la salida de depuración. La cuenta inicial depende de la imagen: no presupongas root ni el mismo usuario en todos los proveedores.
Desde la consola del servidor, adapta la cuenta y su directorio real antes de comprobar:
getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keysgetent permite conocer el directorio de la cuenta. Comprueba propietario y permisos del directorio, .ssh y authorized_keys, y compara la huella con la clave pública de tu ordenador. Nunca copies la clave privada al servidor.
No apliques chmod recursivo a todo el directorio personal ni sustituyas authorized_keys sin conservar entradas que sigan siendo necesarias. Otros métodos de autorización pueden estar configurados: revisa la política real.
Identidad cambiada: verifica antes de aceptar
Una reinstalación o una IP reasignada puede cambiar la clave, pero el aviso también puede señalar una conexión al servidor equivocado. Comprueba identificador de instancia e IP desde el panel autenticado.
En la consola del servidor, para una clave Ed25519:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256Compara tipo y huella SHA256 con el aviso del cliente. Elige el archivo público correspondiente si el aviso usa otro tipo de clave. Solo después de confirmar el cambio legítimo actualiza la entrada precisa de known_hosts; no borres el archivo entero ni uses StrictHostKeyChecking=no para ocultar el problema.
Prueba la corrección en una sesión nueva
Repite una conexión desde otra terminal con usuario, puerto y clave explícitos. Comprueba el acceso sudo que necesites sin cerrar aún la sesión de recuperación. Anota la causa confirmada y la modificación realizada.
Si la corrección afecta la IP permitida o el puerto, revisa también la documentación del despliegue. Para preparar un acceso inicial desde cero, utiliza la guía de configuración del VPS.
Preguntas y respuestas
¿Tengo que reinstalar Ubuntu cuando falla SSH?
Primero diagnostica la fase del fallo desde una consola de confianza. Una reinstalación puede borrar datos y no corrige necesariamente una regla de red externa.
¿Si funciona la consola, debería funcionar SSH?
No necesariamente. La consola utiliza otra vía. SSH necesita dirección, ruta, puerto, servicio y autenticación correctos.