Cómo solucionar errores de conexión SSH en Ubuntu 24.04

Cuando SSH falla, el mensaje de error ya dice en qué fase se ha roto la conexión: la red, el servicio sshd, la verificación de la clave del servidor o la autenticación de tu usuario. En esta guía aprenderás a leer esos mensajes, a obtener más detalle desde el cliente con ssh -v y a revisar el servidor desde la consola cuando SSH no deja entrar. Los comandos del servidor son para Ubuntu 24.04 y valen para Debian 12; las diferencias con Rocky Linux 9 se indican donde importan.

Requisitos previos

Para seguir esta guía necesitas:

• Un servidor con Ubuntu 24.04 LTS (o Debian 12 / Rocky Linux 9), por ejemplo un VPS de CubePath.
• Un cliente SSH en tu equipo: OpenSSH en Linux y macOS, o el cliente OpenSSH incluido en Windows 10 y 11.
• Acceso a la consola del servidor desde el panel de CubePath, para revisar el servidor cuando SSH no funciona.

Sustituye your_user por tu usuario, your_server_ip por la IP del servidor y your_ip por la IP pública de tu equipo.

Paso 1: Identificar el tipo de error

Intenta conectar y fíjate en el mensaje exacto:

ssh your_user@your_server_ip

Cada mensaje apunta a una capa distinta:

Paso 2: Comprobar la red y el puerto

Si el error es un timeout, comprueba primero si el servidor responde:

ping -c 4 your_server_ip

Después comprueba si el puerto SSH acepta conexiones TCP. nc no intenta autenticarse, solo abrir la conexión:

nc -vz -w 5 your_server_ip 22

Connection to your_server_ip 22 port [tcp/ssh] succeeded!

Si el puerto responde, verás además el banner del servidor al conectar sin -z:

nc -w 5 your_server_ip 22

SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.14

Cómo interpretar el resultado:

• Ping y puerto fallan: el servidor está apagado, colgado o hay un problema de red. Abre la consola desde el panel de CubePath para comprobar su estado.
• Ping responde, puerto da timeout: un firewall descarta el tráfico al puerto 22, o SSH escucha en otro puerto. Revisa el paso 7.
• Puerto da Connection refused: el sistema funciona pero sshd no escucha en ese puerto. Revisa el paso 5.
• Puerto conecta pero no aparece el banner: el servidor está saturado o tu IP está bloqueada tras aceptar la conexión. Revisa los pasos 6 y 7.

Si el servidor funciona desde otras redes pero no desde la tuya, prueba a conectar desde otra conexión (por ejemplo, los datos del móvil). Algunas redes corporativas o públicas bloquean el puerto 22 de salida.

Paso 3: Resolver el aviso de clave de host cambiada

Si ves este aviso, SSH se niega a conectar para protegerte:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
...
Offending ED25519 key in /home/your_user/.ssh/known_hosts:12
Host key verification failed.

La clave que presenta el servidor no coincide con la que tu equipo guardó la primera vez. Es normal si has reinstalado el sistema o si la IP ahora pertenece a otro servidor. Si no has hecho ninguno de esos cambios, no continúes: podría ser un ataque de intermediario. Compara la huella desde la consola del servidor con:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Si el cambio es legítimo, elimina la entrada antigua de tu known_hosts:

ssh-keygen -R your_server_ip

# Host your_server_ip found: line 12
/home/your_user/.ssh/known_hosts updated.

Vuelve a conectar y acepta la nueva huella cuando te la pregunte.

Paso 4: Diagnosticar la autenticación desde el cliente

Para errores de autenticación, el modo detallado muestra qué claves prueba el cliente y qué responde el servidor:

ssh -v your_user@your_server_ip

Busca estas líneas en la salida:

debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/your_user/.ssh/id_ed25519 ED25519 SHA256:abc123...
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
your_user@your_server_ip: Permission denied (publickey).

• Authentications that can continue: publickey indica que el servidor solo acepta claves. Si esperabas poder usar contraseña, está desactivada en el servidor.
• Offering public key seguido de otra vez Authentications that can continue significa que el servidor ha rechazado esa clave: no está en su authorized_keys o los permisos del servidor son incorrectos (paso 6).
• Si no aparece ninguna línea Offering public key, el cliente no encuentra tu clave privada.

Comprueba que la clave privada existe y tiene permisos restrictivos. SSH ignora las claves privadas legibles por otros usuarios:

ls -l ~/.ssh/

-rw------- 1 your_user your_user  411 Sep 10 09:12 id_ed25519
-rw-r--r-- 1 your_user your_user  101 Sep 10 09:12 id_ed25519.pub

Si los permisos no son -rw-------, corrígelos:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

Si usas una clave con otro nombre, indícala explícitamente. IdentitiesOnly=yes hace que el cliente solo pruebe esa clave, lo que también resuelve el error Too many authentication failures cuando el agente SSH tiene muchas claves cargadas:

ssh -i ~/.ssh/mi_clave -o IdentitiesOnly=yes your_user@your_server_ip

Revisa también que tu ~/.ssh/config no esté aplicando un usuario, puerto o clave distintos. Este comando muestra la configuración efectiva para un host:

ssh -G your_server_ip | grep -E '^(user|port|identityfile|hostname) '

Paso 5: Comprobar el servicio SSH en el servidor

A partir de aquí necesitas acceso al servidor. Si SSH no funciona, abre la consola desde el panel de CubePath e inicia sesión con tu usuario y contraseña.

En Ubuntu 24.04 SSH usa activación por socket: ssh.socket escucha en el puerto y arranca ssh.service cuando llega una conexión. Comprueba los dos:

sudo systemctl status ssh.socket ssh.service

● ssh.socket - OpenBSD Secure Shell server socket
     Loaded: loaded (/usr/lib/systemd/system/ssh.socket; enabled; preset: enabled)
     Active: active (listening) since Thu 2026-09-25 09:01:12 UTC; 2h ago
     Listen: [::]:22 (Stream)

En Debian 12 y Rocky Linux 9 no hay socket: el servicio se llama ssh en Debian y sshd en Rocky, y debe aparecer como active (running).

Comprueba que algo escucha en el puerto esperado:

sudo ss -tlnp | grep -E ':22\b'

LISTEN 0      4096               *:22              *:*    users:(("sshd",pid=1187,fd=3),("systemd",pid=1,fd=58))

Si el servicio no arranca, lo habitual es un error en la configuración. Valídala; si no hay errores, el comando no muestra nada:

sudo sshd -t

/etc/ssh/sshd_config: line 42: Bad configuration option: PermitRootLogn
/etc/ssh/sshd_config: terminating, 1 bad configuration options

Corrige la línea indicada, vuelve a validar y reinicia:

sudo systemctl restart ssh

Si cambiaste el puerto de SSH

Con la activación por socket de Ubuntu 24.04, cambiar Port en /etc/ssh/sshd_config no basta con reiniciar el servicio: el puerto lo abre ssh.socket. Después de editar el archivo, aplica el cambio así:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Comprueba con sudo ss -tlnp que escucha en el puerto nuevo, y recuerda permitirlo en el firewall (paso 7) antes de cerrar la sesión actual.

Paso 6: Revisar la autenticación en el servidor

Los logs del servidor dicen exactamente por qué se rechazó una conexión. Síguelos mientras intentas conectar desde tu equipo:

sudo journalctl -u ssh -f

En Rocky Linux, usa -u sshd. Estos son los mensajes más frecuentes:

Permisos y propietario de authorized_keys

Con la opción por defecto StrictModes yes, sshd ignora authorized_keys si el home, .ssh o el propio archivo tienen permisos de escritura para otros usuarios o no pertenecen al usuario. Corrígelos (sustituye your_user):

sudo chown -R your_user:your_user /home/your_user/.ssh
sudo chmod 755 /home/your_user
sudo chmod 700 /home/your_user/.ssh
sudo chmod 600 /home/your_user/.ssh/authorized_keys

Comprueba que tu clave pública está en el archivo. Compara su contenido con el de ~/.ssh/id_ed25519.pub de tu equipo; cada clave debe ocupar una sola línea:

sudo cat /home/your_user/.ssh/authorized_keys

Configuración efectiva de sshd

La configuración puede estar repartida entre /etc/ssh/sshd_config y los archivos de /etc/ssh/sshd_config.d/. Por ejemplo, las imágenes cloud suelen incluir 50-cloud-init.conf, que fija PasswordAuthentication. Para ver el valor que realmente se aplica:

sudo sshd -T | grep -Ei '^(port|passwordauthentication|pubkeyauthentication|permitrootlogin|allowusers|allowgroups) '

port 22
permitrootlogin without-password
pubkeyauthentication yes
passwordauthentication no

Si necesitas cambiar una opción, hazlo en un archivo de sshd_config.d/ con un nombre que se cargue antes que los demás (sshd aplica el primer valor que encuentra para cada opción), valida con sudo sshd -t y reinicia con sudo systemctl restart ssh.

Cuenta bloqueada o caducada

Si los logs muestran que la cuenta está bloqueada o la contraseña caducada, comprueba su estado:

sudo passwd -S your_user

your_user P 2026-09-10 0 99999 7 -1

Una L en la segunda columna indica que la contraseña está bloqueada. Desbloquéala con sudo passwd -u your_user o asigna una nueva con sudo passwd your_user.

Paso 7: Revisar el firewall y fail2ban

Comprueba que UFW permite el puerto de SSH:

sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

Si no aparece, permítelo. Si cambiaste el puerto, permite el número concreto (por ejemplo 2222/tcp) en lugar de OpenSSH:

sudo ufw allow OpenSSH

En Rocky Linux, con firewalld:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Si tienes fail2ban, tu IP puede haber quedado bloqueada tras varios intentos fallidos. Este es el caso típico cuando la conexión da timeout solo desde tu red mientras funciona desde otras. Consulta las IPs bloqueadas en la jaula de SSH:

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  `- Total failed:     14
`- Actions
   |- Currently banned: 1
   `- Banned IP list:   203.0.113.25

Si tu IP aparece en la lista, desbloquéala:

sudo fail2ban-client set sshd unbanip your_ip

En Rocky Linux, si cambiaste el puerto de SSH, SELinux también debe permitirlo. Comprueba y añade el puerto con semanage (paquete policycoreutils-python-utils):

sudo semanage port -l | grep ssh_port_t
sudo semanage port -a -t ssh_port_t -p tcp 2222

Paso 8: Depurar sshd en un puerto aparte

Si los logs no dejan clara la causa, ejecuta una segunda instancia de sshd en modo depuración en otro puerto. No toca el servicio principal, así que no pierdes el acceso actual. Crea el directorio que sshd necesita y permite el puerto temporalmente:

sudo mkdir -p /run/sshd
sudo ufw allow 2222/tcp
sudo /usr/sbin/sshd -d -p 2222

Desde tu equipo, conecta a ese puerto:

ssh -p 2222 your_user@your_server_ip

La terminal del servidor mostrará paso a paso cómo evalúa la conexión, incluyendo líneas como debug1: trying public key file /home/your_user/.ssh/authorized_keys y el motivo exacto de cualquier rechazo. La instancia termina sola después de una conexión. Al acabar, elimina la regla temporal:

sudo ufw delete allow 2222/tcp

Conclusión

Has aprendido a identificar en qué capa falla SSH a partir del mensaje de error, a comprobar la red y el puerto con nc, a leer la salida de ssh -v y, desde la consola, a revisar ssh.socket, la configuración efectiva de sshd, los permisos de authorized_keys, el firewall y fail2ban. Con los logs del servidor y el modo depuración, casi cualquier fallo de conexión queda explicado en unos minutos.

Como siguientes pasos, puedes:

• Mantener una contraseña para tu usuario, aunque SSH solo acepte claves, para poder entrar siempre por la consola del panel.
• Definir tus servidores en ~/.ssh/config con su usuario, puerto y clave para evitar errores al conectar.
• Antes de cambiar la configuración de SSH, dejar una sesión abierta y probar la nueva conexión desde otra terminal.