Solución de problemas de permisos SSH denegados (publickey)

Permiso denegado (publickey) significa que el servidor era accesible, pero no aceptó ningún intento de autenticación de clave pública para el usuario que intentaste. Esto reduce el problema. Ya no estás depurando enrutamiento, DNS o si el puerto SSH está abierto. Estás depurando la identidad: el nombre de usuario, la clave privada que ofreció tu cliente, la clave pública almacenada en el servidor y las reglas del servidor que deciden si se permite ese inicio de sesión.

El comando más rápido y útil es:

ssh -vvv usuario@tu_ip_del_servidor

Busca Autenticando a ... como 'usuario', luego busca Ofreciendo clave pública. Si no se ofrece la clave esperada, arregla el cliente. Si se ofrece la clave esperada y es rechazada, arregla el authorized_keys del lado del servidor, la propiedad, los permisos o la política del demonio SSH.

Causas comunes de 'Permiso denegado (publickey)'

El error "Permiso denegado (publickey)" puede deberse a varios problemas de configuración. Identificar la causa raíz a menudo implica verificar sistemáticamente los siguientes componentes:

• Permisos de archivo incorrectos: SSH es muy sensible a los permisos de archivos y directorios por razones de seguridad. Los permisos incorrectos en tu directorio local ~/.ssh, el archivo de clave privada, o en el directorio ~/.ssh del servidor y el archivo authorized_keys pueden impedir la autenticación.
• Entrada authorized_keys faltante o incorrecta: El archivo authorized_keys del servidor debe contener la clave pública correcta para el usuario con el que intentas iniciar sesión. Si la clave falta, está mal formada o asociada al usuario incorrecto, la autenticación fallará.
• Asociación incorrecta del par de claves: Tu cliente SSH podría estar ofreciendo la clave privada incorrecta, o el servidor podría no tener la clave pública correspondiente listada en el archivo authorized_keys.
• Problemas con el agente SSH: Si estás usando un agente SSH, es posible que no tenga cargada correctamente tu clave privada, o que esté configurado incorrectamente.
• Configuración SSH del lado del servidor: Aunque es menos común para este error específico, la configuración del demonio SSH del servidor (sshd_config) podría tener restricciones específicas sobre la autenticación de clave pública.

Guía de solución de problemas paso a paso

Profundicemos en los pasos prácticos para diagnosticar y solucionar estos problemas.

1. Verificar la clave privada local y los permisos

Tu configuración SSH local es lo primero que debes revisar. Asegúrate de que tu clave privada sea accesible y tenga los permisos correctos.

Verificar la existencia de la clave privada

Tu clave privada a menudo se encuentra en ~/.ssh/id_ed25519 o ~/.ssh/id_rsa, pero muchos equipos usan nombres específicos del proyecto. Lista tus claves:

ls -la ~/.ssh

No subas ni pegues una clave privada en authorized_keys. El servidor necesita el contenido del archivo .pub, no la clave privada.

Verificar los permisos de archivos locales

El directorio ~/.ssh y tu archivo de clave privada deben tener permisos restrictivos para evitar el acceso no autorizado.

• Directorio ~/.ssh: Debe ser 700 (drwx------).
• Archivo de clave privada (ej., id_rsa): Debe ser 600 (-rw-------).

Usa el comando chmod para establecer los permisos correctos:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa

Consejo: Si estás usando un nombre de clave diferente, reemplaza id_rsa con el nombre real de tu archivo de clave privada.

Si estás probando una clave específica, fórzala:

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

Esto evita que tu agente ofrezca primero una larga lista de claves no relacionadas.

2. Verificar la configuración de authorized_keys del lado del servidor

Este suele ser el culpable más común. El servidor debe tener tu clave pública listada correctamente para el usuario con el que intentas autenticarte.

Acceder al servidor (si es posible)

Si aún puedes acceder al servidor a través de otro método (ej., autenticación por contraseña, otra cuenta de usuario o una consola), inicia sesión para verificar el archivo authorized_keys.

Verificar la ubicación del archivo authorized_keys

El archivo authorized_keys generalmente se encuentra en ~/.ssh/authorized_keys dentro del directorio de inicio del usuario con el que intentas iniciar sesión.

Verificar los permisos de archivos del lado del servidor

Al igual que en el lado del cliente, los permisos del lado del servidor son críticos:

• Directorio ~/.ssh en el servidor: Debe ser 700 (drwx------).
• Archivo authorized_keys en el servidor: Debe ser 600 (-rw-------).

Asegúrate de que estos permisos estén configurados correctamente en el servidor:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

También verifica la propiedad. El directorio .ssh y el archivo authorized_keys normalmente deben pertenecer a la cuenta con la que estás iniciando sesión:

chown -R tuusuario:tuusuario ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Si StrictModes está habilitado en sshd_config, OpenSSH puede rechazar claves cuando el directorio de inicio o la ruta .ssh son escribibles por usuarios incorrectos.

Verificar el contenido de authorized_keys

Abre el archivo ~/.ssh/authorized_keys usando un editor de texto (ej., nano, vim). Cada clave pública debe estar en una sola línea. Asegúrate de que la clave pública que esperas usar esté presente y tenga el formato correcto. Debe comenzar con ssh-rsa, ssh-ed25519 o similar, seguido de una larga cadena de caracteres y, opcionalmente, un comentario.

Ejemplo de entrada en authorized_keys:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD... tu_cadena_de_clave_pública usuario@hostname

No agregues tu clave privada a authorized_keys. Solo la clave pública debe estar aquí.

3. Asegurarse de que se agregó la clave pública correcta

Es posible que se haya copiado la clave pública incorrecta o que la clave pública en el servidor no coincida con tu clave privada local.

Recuperar tu clave pública local

Tu clave pública es la contraparte de tu clave privada. Puedes verla usando el comando ssh-keygen:

cat ~/.ssh/id_rsa.pub

Este comando mostrará tu clave pública. Compara cuidadosamente esta salida con la entrada en el archivo ~/.ssh/authorized_keys del servidor. Incluso un solo error tipográfico o un carácter faltante hará que la autenticación falle.

Para una comparación más limpia, imprime la clave pública derivada de la clave privada que intentas usar:

ssh-keygen -y -f ~/.ssh/id_ed25519_prod

Esa salida debe coincidir con una línea en el authorized_keys del usuario remoto.

Consejo: Una forma rápida de agregar tu clave pública si tienes acceso por contraseña al servidor es usar ssh-copy-id.

ssh-copy-id usuario@tu_ip_del_servidor

Este comando agrega automáticamente tu clave pública predeterminada (~/.ssh/id_rsa.pub) al archivo ~/.ssh/authorized_keys en el servidor remoto y establece los permisos correctos.

4. Especificar la clave privada correcta (si no es la predeterminada)

Si estás usando una clave privada no predeterminada (ej., ~/.ssh/mi_otra_clave), debes indicarle a tu cliente SSH qué clave usar.

Usar la bandera -i

Puedes especificar el archivo de identidad (clave privada) con la opción -i:

ssh -i ~/.ssh/mi_otra_clave usuario@tu_ip_del_servidor

Configurar ~/.ssh/config

Para mayor comodidad, puedes configurar tu cliente SSH para que siempre use una clave específica para un host determinado:

Crea o edita el archivo ~/.ssh/config en tu máquina local y agrega una entrada como esta:

Host alias_de_tu_servidor
  HostName tu_ip_o_dominio_del_servidor
  User tu_nombre_de_usuario
  IdentityFile ~/.ssh/mi_otra_clave
  IdentitiesOnly yes

Luego puedes conectarte simplemente usando:

ssh alias_de_tu_servidor

5. Verificar el estado del agente SSH

Si dependes de un agente SSH para administrar tus claves, asegúrate de que se esté ejecutando y tenga tu clave cargada.

Verificar si el agente se está ejecutando

echo "$SSH_AUTH_SOCK"

Si esto muestra una ruta, es probable que el agente se esté ejecutando. Si está vacío, es posible que necesites iniciar uno.

Agregar clave al agente

Si tu clave no está cargada, agrégala:

ssh-add ~/.ssh/id_rsa

Si se te solicita una frase de contraseña, introdúcela. Puedes verificar qué claves se agregaron con ssh-add -l.

Si ssh-add -l muestra muchas claves no relacionadas y el servidor se desconecta después de varios intentos, elimina las claves antiguas del agente o usa IdentitiesOnly yes para ese host.

6. Depuración con modo verbose

SSH tiene un modo verbose (-v, -vv o -vvv para niveles crecientes de detalle) que puede proporcionar pistas invaluables sobre dónde está fallando el proceso de autenticación.

ssh -vvv usuario@tu_ip_del_servidor

Examina la salida en busca de mensajes relacionados con la autenticación de claves, ofrecimiento de claves y respuestas del servidor. Esto a menudo apunta directamente al problema.

Ejemplo de fragmento de salida verbose que indica un fallo de publickey:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: read PEM private key file /home/user/.ssh/id_rsa
debug1: failed to use sshkey: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

Esta salida significa que el cliente intentó id_rsa, el servidor no lo aceptó y el cliente pasó al siguiente método permitido.

7. Revisión de sshd_config del lado del servidor (Avanzado)

Verifica /etc/ssh/sshd_config y cualquier archivo en /etc/ssh/sshd_config.d/. Confirma que la autenticación de clave pública esté habilitada:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Luego busca bloques Match cerca del final del archivo. Un bloque posterior Match User, Match Group o Match Address puede anular configuraciones anteriores para la cuenta exacta que estás probando.

Después de cualquier cambio, valida la sintaxis antes de recargar:

sudo sshd -t
sudo systemctl reload sshd

Algunos sistemas usan ssh como nombre del servicio en lugar de sshd.

Un orden de solución de problemas confiable

Usa la salida verbose para evitar adivinar. Primero confirma el nombre de usuario. Luego confirma que el cliente ofrece la clave privada que esperas. Luego confirma que la clave pública coincidente está en el authorized_keys del usuario objetivo. Luego verifica la propiedad y los permisos. Solo después de que estos estén limpios, debes dedicar tiempo a sshd_config, bloques Match, contextos SELinux o restricciones de cuenta.

Ese orden resuelve la mayoría de los casos de Permiso denegado (publickey) sin cambios aleatorios, y evita que debilites la seguridad SSH solo para lograr un inicio de sesión urgente.