--- title: "Cómo solucionar errores de conexión SSH en Ubuntu 24.04" description: "Diagnostica por qué no puedes conectar por SSH: timeouts, Connection refused, Permission denied (publickey) o clave de host cambiada, con causa y solución." category: "Guía de Solución de Problemas" language: es source: https://cubepath.com/es/docs/guía-de-solución-de-problemas/diagnostico-de-problemas-de-conectividad-ssh updated: 2026-09-25 --- # 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: ```bash ssh your_user@your_server_ip ``` Cada mensaje apunta a una capa distinta: | Mensaje | Qué significa | Dónde buscar | |---------|---------------|--------------| | `Connection timed out` | Los paquetes no llegan o se descartan | Red, firewall, servidor apagado (paso 2) | | `Connection refused` | El servidor responde, pero nada escucha en ese puerto | Servicio SSH, puerto (paso 5) | | `Could not resolve hostname` | El nombre no resuelve a una IP | DNS o error tipográfico | | `REMOTE HOST IDENTIFICATION HAS CHANGED` | La clave del servidor no coincide con la guardada | Reinstalación o cambio de IP (paso 3) | | `Permission denied (publickey)` | El servidor rechaza tu clave y no admite contraseña | Claves y permisos (pasos 4 y 6) | | `Too many authentication failures` | El cliente ha probado demasiadas claves | Agente SSH (paso 4) | | `Connection closed by your_server_ip port 22` | El servidor corta durante la negociación | Logs del servidor, fail2ban (pasos 6 y 7) | ## Paso 2: Comprobar la red y el puerto Si el error es un timeout, comprueba primero si el servidor responde: ```bash 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: ```bash nc -vz -w 5 your_server_ip 22 ``` ```output 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`: ```bash nc -w 5 your_server_ip 22 ``` ```output 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: ```output @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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: ```bash ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub ``` Si el cambio es legítimo, elimina la entrada antigua de tu `known_hosts`: ```bash ssh-keygen -R your_server_ip ``` ```output # 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: ```bash ssh -v your_user@your_server_ip ``` Busca estas líneas en la salida: ```output 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: ```bash ls -l ~/.ssh/ ``` ```output -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: ```bash 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: ```bash 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: ```bash 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: ```bash sudo systemctl status ssh.socket ssh.service ``` ```output ● 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: ```bash sudo ss -tlnp | grep -E ':22\b' ``` ```output 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: ```bash sudo sshd -t ``` ```output /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: ```bash 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í: ```bash 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: ```bash sudo journalctl -u ssh -f ``` En Rocky Linux, usa `-u sshd`. Estos son los mensajes más frecuentes: | Mensaje en el log | Causa | |-------------------|-------| | `Authentication refused: bad ownership or modes for directory /home/your_user/.ssh` | Permisos demasiado abiertos en el home, `.ssh` o `authorized_keys` | | `User your_user not allowed because not listed in AllowUsers` | Restricción `AllowUsers` o `AllowGroups` en `sshd_config` | | `Invalid user admin from 198.51.100.7` | El usuario no existe en el servidor | | `Failed password for your_user` | Contraseña incorrecta | | `Connection closed by authenticating user your_user ... [preauth]` | El cliente abandonó tras un rechazo; mira las líneas anteriores | ### 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`): ```bash 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: ```bash 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: ```bash sudo sshd -T | grep -Ei '^(port|passwordauthentication|pubkeyauthentication|permitrootlogin|allowusers|allowgroups) ' ``` ```output 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: ```bash sudo passwd -S your_user ``` ```output 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: ```bash sudo ufw status ``` ```output 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`: ```bash sudo ufw allow OpenSSH ``` En Rocky Linux, con firewalld: ```bash 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: ```bash sudo fail2ban-client status sshd ``` ```output 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: ```bash 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`): ```bash 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: ```bash sudo mkdir -p /run/sshd sudo ufw allow 2222/tcp sudo /usr/sbin/sshd -d -p 2222 ``` Desde tu equipo, conecta a ese puerto: ```bash 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: ```bash 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.