Solución de problemas de SSH: Errores de "Permiso denegado (publickey)"
Al intentar conectarse a un servidor remoto a través de SSH, encontrar el error "Permission Denied (publickey)" (Permiso denegado (publickey)) puede ser un obstáculo frustrante. Este error indica específicamente que el servidor rechazó su conexión porque no pudo autenticarlo utilizando su clave pública. A diferencia de la autenticación basada en contraseña, la criptografía de clave pública se basa en un par de claves: una clave privada que se mantiene secreta en su máquina local y una clave pública colocada en el servidor. Esta guía le mostrará las causas comunes de este error y le proporcionará pasos detallados para diagnosticarlas y resolverlas, asegurando un acceso SSH seguro y sin interrupciones.
Comprender el proceso de autenticación de clave pública de SSH es crucial para una solución de problemas efectiva. Cuando intenta conectarse, su cliente SSH presenta su clave pública al servidor. Luego, el servidor comprueba si esa clave pública está autorizada para su cuenta de usuario. Si lo está, el servidor cifra un desafío con su clave pública y lo envía de vuelta. Su cliente, que posee la clave privada correspondiente, descifra el desafío y envía la respuesta al servidor. Si la respuesta es correcta, la autenticación tiene éxito. Un error de "Permission Denied (publickey)" significa que este intercambio falló en algún momento.
Causas comunes de "Permiso denegado (publickey)"
El error "Permission Denied (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 su directorio local
~/.ssh, el archivo de clave privada, o en el directorio~/.sshdel lado del servidor y el archivoauthorized_keyspueden impedir la autenticación. - Entrada faltante o incorrecta en
authorized_keys: El archivoauthorized_keysdel servidor debe contener la clave pública correcta para el usuario con el que está intentando iniciar sesión. Si falta la clave, tiene un formato incorrecto o está asociada con el usuario equivocado, la autenticación fallará. - Asociación incorrecta del par de claves: Su cliente SSH podría estar ofreciendo la clave privada equivocada, o es posible que el servidor no tenga la clave pública correspondiente listada en el archivo
authorized_keys. - Problemas con el agente SSH: Si está utilizando un agente SSH, es posible que no se haya cargado correctamente con su 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. Verifique la clave privada local y los permisos
La configuración SSH local es el primer lugar para verificar. Asegúrese de que su clave privada sea accesible y tenga los permisos correctos.
Comprobación de la existencia de la clave privada
Su clave privada se encuentra generalmente en ~/.ssh/id_rsa (o id_ed25519, id_dsa, etc.).
Verificación de los permisos de archivo locales
El directorio ~/.ssh y su archivo de clave privada deben tener permisos restrictivos para evitar el acceso no autorizado.
- Directorio
~/.ssh: Debe ser700(drwx------). - Archivo de clave privada (ej.
id_rsa): Debe ser600(-rw-------).
Use el comando chmod para establecer los permisos correctos:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
Consejo: Si está utilizando un nombre de clave diferente, reemplace id_rsa con el nombre de su archivo de clave privada real.
2. Verifique la configuración del authorized_keys del lado del servidor
Este es a menudo el culpable más común. El servidor debe tener su clave pública correctamente listada para el usuario con el que intenta autenticarse.
Acceder al servidor (si es posible)
Si aún puede acceder al servidor a través de otro método (ej. autenticación por contraseña, otra cuenta de usuario o una consola), inicie sesión para verificar el archivo authorized_keys.
Comprobación de la ubicación del archivo authorized_keys
El archivo authorized_keys se encuentra típicamente en ~/.ssh/authorized_keys dentro del directorio principal del usuario con el que intenta iniciar sesión.
Verificación de los permisos de archivo del lado del servidor
Similar al lado del cliente, los permisos del lado del servidor son críticos:
- Directorio
~/.sshen el servidor: Debe ser700(drwx------). - Archivo
authorized_keysen el servidor: Debe ser600(-rw-------).
Asegúrese de que estos permisos estén configurados correctamente en el servidor:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Verificación del contenido de authorized_keys
Abra 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úrese de que la clave pública que espera usar esté presente y formateada correctamente. 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... su_cadena_de_clave_publica usuario@nombre_host
Importante: No agregue su clave privada a authorized_keys. Solo la clave pública debe estar aquí.
3. Asegúrese de que se agregó la clave pública correcta
Es posible que se haya copiado la clave pública equivocada o que la clave pública en el servidor no coincida con su clave privada local.
Recuperación de su clave pública local
Su clave pública es el homólogo de su clave privada. Puede verla usando el comando ssh-keygen:
cat ~/.ssh/id_rsa.pub
Este comando mostrará su clave pública. Compare esta salida cuidadosamente 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.
Consejo: Una forma rápida de agregar su clave pública si tiene acceso por contraseña al servidor es usando ssh-copy-id.
ssh-copy-id usuario@su_ip_del_servidor
Este comando agrega automáticamente su clave pública predeterminada (~/.ssh/id_rsa.pub) al archivo ~/.ssh/authorized_keys en el servidor remoto y establece los permisos correctos.
4. Especifique la clave privada correcta (si no es la predeterminada)
Si está utilizando una clave privada no predeterminada (ej. ~/.ssh/my_other_key), debe indicarle a su cliente SSH qué clave usar.
Uso de la opción -i
Puede especificar el archivo de identidad (clave privada) con la opción -i:
ssh -i ~/.ssh/my_other_key usuario@su_ip_del_servidor
Configuración de ~/.ssh/config
Para mayor comodidad, puede configurar su cliente SSH para que siempre use una clave específica para un host determinado:
Cree o edite el archivo ~/.ssh/config en su máquina local y agregue una entrada como esta:
Host alias_de_su_servidor
HostName su_ip_o_dominio_del_servidor
User su_nombre_de_usuario
IdentityFile ~/.ssh/my_other_key
Luego puede conectarse simplemente usando:
ssh alias_de_su_servidor
5. Verifique el estado del agente SSH
Si depende de un agente SSH para administrar sus claves, asegúrese de que se esté ejecutando y tenga su clave cargada.
Verificación de 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 deba iniciar uno.
Agregar clave al agente
Si su clave no está cargada, agréguela:
ssh-add ~/.ssh/id_rsa
Si se le solicita una frase de contraseña, ingrésela. Puede verificar qué claves están agregadas con ssh-add -l.
6. Depuración con modo detallado
SSH tiene un modo detallado (-v, -vv, o -vvv para aumentar los niveles de detalle) que puede proporcionar pistas invaluables sobre dónde está fallando el proceso de autenticación.
ssh -vvv usuario@su_ip_del_servidor
Examine la salida en busca de mensajes relacionados con la autenticación de claves, la oferta de claves y las respuestas del servidor. Esto a menudo apunta directamente al problema.
Fragmento de salida detallada 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 podría indicar que el cliente intentó usar id_rsa pero falló, y luego pasó a otros métodos.
7. Revisión de sshd_config del lado del servidor (Avanzado)
Aunque es menos común para errores específicos de publickey (normalmente aparecerían otros errores), vale la pena señalar el archivo de configuración del demonio SSH del servidor (/etc/ssh/sshd_config). Asegúrese de que PubkeyAuthentication yes no esté comentado y esté configurado como yes. Después de realizar cualquier cambio, el servicio SSH debe recargarse o reiniciarse (ej. sudo systemctl reload sshd o sudo systemctl restart sshd).
Resumen y mejores prácticas
Solucionar los errores SSH "Permission Denied (publickey)" implica una verificación metódica tanto de la configuración del cliente como del servidor. Las causas más frecuentes se relacionan con permisos de archivo incorrectos en los archivos ~/.ssh y authorized_keys, y discrepancias entre la clave pública en el servidor y la clave privada en el cliente.
Puntos clave:
- Los permisos son primordiales: Asegúrese siempre de que
~/.sshsea700y que las claves privadas/authorized_keyssean600tanto en el cliente como en el servidor. - Precisión de la clave pública: Vuelva a comprobar que la clave pública exacta esté presente en el archivo
authorized_keysdel servidor. - Use
ssh-copy-id: Cuando sea posible, esta es la forma más segura y sencilla de configurar la autenticación de clave pública. - Modo detallado: Utilice
ssh -vvvpara obtener una salida de diagnóstico detallada.
Siguiendo estos pasos, debería poder diagnosticar y resolver la mayoría de los problemas de "Permission Denied (publickey)", restaurando el acceso remoto seguro a sus servidores.