Solución de problemas comunes de SSH: Errores de 'Permiso denegado' y problemas de conexión

Secure Shell (SSH) es la base de la gestión remota de servidores, ofreciendo comunicación cifrada para acceder y controlar sistemas remotos. Aunque es fiable, la configuración de SSH, especialmente con autenticación basada en claves, a veces puede llevar a frustrantes fallos de conexión. El culpable más común es el temido error Permission denied.

Esta guía completa le ayudará a diagnosticar y resolver los errores de SSH más frecuentes. Nos centraremos específicamente en comprender las causas raíz detrás de Permission denied (publickey) y abordaremos los errores comunes relacionados con los permisos de archivos, la configuración incorrecta y las discrepancias en la configuración cliente/servidor. Dominar estos pasos de solución de problemas garantiza un acceso seguro y fiable a su infraestructura remota.

Entendiendo el flujo de autenticación SSH

Antes de solucionar problemas, es crucial entender cómo SSH autentica a los usuarios. Cuando intenta conectarse, el servidor normalmente comprueba las credenciales en el siguiente orden (dependiendo de la configuración):

Autenticación de clave pública: El cliente presenta una clave pública y el servidor comprueba si la clave privada correspondiente es válida y coincide con una clave autorizada (archivo authorized_keys).
Autenticación por contraseña: Si la autenticación por clave falla o está deshabilitada, el servidor solicita una contraseña.

Cuando recibe Permission denied, casi siempre significa que el servidor rechazó sus credenciales durante el paso 1 o 2.

Diagnóstico de problemas de conexión: El poder del modo detallado (verbose)

La herramienta más eficaz para diagnosticar problemas de SSH es ejecutar el cliente en modo detallado. Al añadir los indicadores -v, -vv o -vvv, el cliente genera información de depuración detallada sobre el proceso de negociación.

Uso de indicadores detallados (verbose)

Utilice la siguiente estructura de comando:

ssh -vvv user@remote_host

Qué buscar en la salida:

Intercambio de claves: Busque líneas que indiquen qué métodos de autenticación intentó el cliente (por ejemplo, Offering RSA key: /path/to/id_rsa).
Respuesta del servidor: Preste mucha atención a los mensajes de rechazo del servidor. Si la salida muestra que el servidor está comprobando claves pero no logra coincidir, el problema probablemente sea la configuración de la clave o los permisos en el lado del servidor.
Solicitud de contraseña: Si la salida omite las comprobaciones de clave e inmediatamente solicita una contraseña, la autenticación por clave puede estar deshabilitada en el servidor.

Resolución de `Permission denied (publickey)`

Este error indica explícitamente que el servidor rechazó la credencial de clave pública proporcionada. La solución generalmente reside en los permisos o el emparejamiento de claves.

1. Comprobar los permisos del archivo de clave (lado del cliente)

Por seguridad, los clientes SSH son muy estrictos con los permisos de su archivo de clave privada (por ejemplo, ~/.ssh/id_rsa). Si estos archivos son demasiado abiertos, el cliente se negará a utilizarlos.

Solución práctica (cliente): Asegúrese de que su clave privada solo sea legible por usted.

chmod 600 ~/.ssh/id_rsa

2. Verificar la existencia y el uso correcto de la clave

Asegúrese de que se está conectando con el archivo de identidad correcto, especialmente si utiliza claves no estándar o múltiples pares de claves.

Solución práctica (cliente): Especifique la clave privada correcta utilizando el indicador -i.

ssh -i /path/to/your/specific_private_key user@remote_host

3. Permisos y propiedad del lado del servidor

Esta es la fuente más común de fallos. SSH impone permisos estrictos de directorio y archivo en el servidor para el usuario con el que intenta iniciar sesión.

Ruta en el servidor	Permisos requeridos	Propietario
Directorio `~/.ssh`	`700` (rwx------)	Usuario
Archivo `~/.ssh/authorized_keys`	`600` (rw-------)	Usuario

Solución práctica (servidor): Inicie sesión a través de la consola o la autenticación por contraseña (si está habilitada) y ejecute estos comandos:

# Establecer permisos de directorio
chmod 700 ~/.ssh

# Establecer permisos de authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Verificar propiedad (reemplace 'myuser' con el nombre de usuario real)
chown -R myuser:myuser ~/.ssh

Advertencia: Si los permisos del directorio de inicio del usuario (~/) son demasiado amplios (por ejemplo, escribibles por grupo u otros), SSH también podría fallar por razones de seguridad. Apunte a 755 o más estricto en ~/ si persisten los problemas.

4. Confirmar que la clave se ha añadido correctamente

Asegúrese de que la cadena de la clave pública en el cliente coincide exactamente con lo que está pegado en el archivo ~/.ssh/authorized_keys del servidor. Un carácter faltante o un espacio en blanco al final causarán un fallo de autenticación.

Consejo: Al añadir una clave, utilice ssh-copy-id si está disponible, ya que maneja los permisos y el formato automáticamente:

ssh-copy-id user@remote_host

Solución de problemas de archivos de configuración (`sshd_config`)

Si las claves y los permisos son correctos, el problema a menudo reside en el archivo de configuración del demonio SSH, típicamente ubicado en /etc/ssh/sshd_config en el servidor.

1. Comprobar los métodos de autenticación

Asegúrese de que la autenticación de clave pública esté explícitamente permitida.

Verificación de configuración: Busque las siguientes líneas y asegúrese de que no estén comentadas (#) y estén configuradas correctamente:

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

2. Estado de la autenticación por contraseña

Si depende del inicio de sesión por contraseña temporalmente, verifique que esté habilitado. Si está establecido en no, debe usar claves.

PasswordAuthentication yes

3. Permitir inicio de sesión de root (`PermitRootLogin`)

Si intenta iniciar sesión como root, asegúrese de que esto esté permitido. La mejor práctica es generalmente iniciar sesión como un usuario estándar y usar sudo, pero para solucionar problemas, puede verificar esta configuración:

PermitRootLogin yes

Paso crucial: Después de cualquier cambio en /etc/ssh/sshd_config, debe reiniciar el servicio SSH para que los cambios surtan efecto:
bash sudo systemctl restart sshd # O service ssh restart

Otros errores comunes de conexión

Aunque los problemas de claves son los principales, otros errores pueden bloquear el acceso:

A. Conexión agotada (`Connection Timed Out`)

Esto generalmente significa que el cliente no pudo alcanzar el servidor en absoluto, lo que indica un problema de red, no un problema de autenticación.

Posibles causas:
* El servidor está caído o inaccesible.
* Un firewall (local o de red) está bloqueando la conexión en el puerto 22 (o puerto SSH personalizado).
* Dirección IP o nombre de host incorrectos.

Solución de problemas: Utilice ping para verificar la conectividad básica, y telnet o nc (netcat) para verificar si el puerto está abierto:

# Comprobar si el puerto 22 es accesible
telnet remote_host 22

B. No hay ruta al host (`No Route to Host`)

Similar al tiempo de espera, este es un problema de infraestructura de red. El cliente no puede encontrar una ruta a la dirección IP del servidor. Verifique las tablas de enrutamiento, el estado de la VPN o asegúrese de que el servidor remoto tenga una interfaz de red válida activa.

C. El servidor rechazó nuestra clave (`Server Refused Our Key`)

Si la salida detallada muestra que el servidor está rechazando activamente las claves pero ha verificado el archivo authorized_keys, verifique los contextos de seguridad de SELinux o AppArmor en el servidor. Estos módulos de seguridad pueden anular los permisos de archivo y bloquear el acceso SSH si los contextos son incorrectos.

Resumen de las mejores prácticas

Utilice siempre el modo detallado (-vvv) para el diagnóstico.
Seguridad de la clave del cliente: Asegúrese de que las claves privadas estén configuradas en 600 (chmod 600).
Integridad del archivo del servidor: Verifique que ~/.ssh sea 700 y authorized_keys sea 600.
Reiniciar el demonio: Siempre reinicie sshd después de modificar /etc/ssh/sshd_config.
Utilice ssh-copy-id siempre que sea posible para automatizar la implementación de claves.