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

Un error SSH Permiso denegado generalmente significa que el servidor era accesible, pero se negó a autenticarte. Esto es diferente de Tiempo de conexión agotado, Conexión rechazada o Sin ruta al host. Tratar todos ellos como "SSH está roto" pierde tiempo, así que comienza separando los fallos de autenticación de los fallos de red.

Ejecuta el comando fallido con registro verbose:

ssh -vvv usuario@host_remoto

Estás buscando pistas claras: qué nombre de usuario usó el cliente, qué archivos de clave ofreció, si el servidor aceptó alguna clave y qué métodos de autenticación quedan. La mayoría de las correcciones a continuación provienen de hacer coincidir esas pistas con el estado del lado del servidor.

Comprensión del flujo de autenticación SSH

Cuando intentas conectarte, el servidor solo permite los métodos de autenticación habilitados en su configuración. Un servidor típico intenta primero la autenticación de clave pública y puede permitir la autenticación por contraseña después, dependiendo de la política:

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

Cuando recibes Permiso denegado, la conexión TCP funcionó. El servidor simplemente no aceptó la credencial que presentaste para ese usuario.

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

La herramienta más efectiva para diagnosticar problemas SSH es ejecutar el cliente en modo verbose. Al agregar las banderas -v, -vv o -vvv, el cliente muestra información detallada de depuración sobre el proceso de negociación.

Uso de banderas verbose

Usa la siguiente estructura de comando:

ssh -vvv usuario@host_remoto

Qué buscar en la salida:

• Nombre de usuario: Busca Autenticando a ... como 'usuario'. Un nombre de usuario Linux incorrecto es uno de los errores más fáciles de pasar por alto.
• Claves ofrecidas: Busca Ofreciendo clave pública. Si la clave esperada nunca aparece, corrige la configuración del cliente.
• Respuesta del servidor: Si cada clave ofrecida es seguida por Autenticaciones que pueden continuar, el servidor rechazó esas claves.
• Métodos de autenticación: Si publickey no está listado, el servidor puede no permitir la autenticación de clave para esa cuenta o bloque de host.

---

Resolviendo Permiso denegado (publickey)

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

1. Verificar permisos del archivo de clave (lado del cliente)

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

Asegúrate de que tu clave privada solo sea legible por ti:

chmod 600 ~/.ssh/id_rsa

2. Verificar existencia de clave y uso correcto de clave

Asegúrate de estar conectando con el archivo de identidad correcto, especialmente si usas claves no estándar o múltiples pares de claves.

Especifica la clave privada correcta usando la bandera -i:

ssh -i /ruta/a/tu/clave_privada_específica usuario@host_remoto

Si tu agente tiene muchas claves cargadas, agrega IdentitiesOnly=yes para esta prueba:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod usuario@host_remoto

3. Permisos y propiedad del lado del servidor

Esta es la fuente más común de fallo de autenticación de clave. SSH impone permisos estrictos de directorio y archivo en el servidor para el usuario al que intentas iniciar sesión.

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

Inicia sesión a través de consola, consola serial en la nube, autenticación por contraseña u otra cuenta de administrador y ejecuta estos comandos como el usuario objetivo o con la ruta correcta:

# Establecer permisos del directorio
chmod 700 ~/.ssh

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

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

Si el directorio home del usuario es escribible por el grupo u otros, OpenSSH también puede rechazar la clave cuando StrictModes está habilitado. Verifica con:

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

Para la mayoría de los hogares de usuario normales, 755 o más estricto está bien.

4. Confirmar que la clave está realmente agregada

Asegúrate de que la clave pública en el cliente coincida con la que está pegada en el archivo ~/.ssh/authorized_keys del servidor. Un carácter faltante, una línea envuelta o una clave privada copiada causarán un fallo de autenticación.

Al agregar una clave, usa ssh-copy-id si el acceso por contraseña aún está disponible:

ssh-copy-id usuario@host_remoto

---

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

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

1. Verificar métodos de autenticación

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

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

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

También verifica los bloques Match cerca del final del archivo. Una configuración global puede permitir claves públicas, mientras que un bloque posterior Match User, Match Group o Match Address las deshabilita para el inicio de sesión exacto que estás probando.

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

Si estás confiando temporalmente en el inicio de sesión por contraseña, verifica que esté habilitado. Si está configurado como no, debes usar claves.

PasswordAuthentication yes

3. PermitRootLogin

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

PermitRootLogin prohibit-password

Para el inicio de sesión de root, muchos sistemas predeterminan el acceso solo por clave o deshabilitan completamente el inicio de sesión de root. Prefiere un usuario normal con sudo. Si debes cambiar la configuración del demonio SSH, valida la sintaxis antes de recargar:

sudo sshd -t
sudo systemctl reload sshd  # Algunos sistemas usan: sudo systemctl reload ssh

---

Otros errores comunes de conexión

Si bien los problemas de clave son primarios, otros errores pueden bloquear el acceso:

A. Tiempo de conexión agotado

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

Causas posibles:

• El servidor está caído o inalcanzable.
• 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 incorrecto.

Usa ping para una pista básica de accesibilidad y nc para verificar el puerto SSH:

nc -vz host_remoto 22

B. Sin ruta al host

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

C. El servidor rechazó nuestra clave

Si la salida verbose muestra que el servidor está rechazando activamente las claves pero has verificado el archivo authorized_keys, verifica los contextos de seguridad 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.

Un orden práctico que generalmente funciona

Verifica el nombre de usuario primero. Luego fuerza la clave que esperas con ssh -o IdentitiesOnly=yes -i .... Si el cliente ofrece la clave correcta y el servidor la rechaza, inspecciona authorized_keys, la propiedad y los permisos en el servidor. Si la clave nunca se ofrece, corrige tu ~/.ssh/config local, agente o ruta de clave. Si la conexión nunca llega a la autenticación, cambia a la solución de problemas de red en lugar de cambiar archivos de clave.