Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red: https://www.alcancelibre.org
Licencia Creative Commons
© 1999-2026 Joel Barrios Dueñas. Este manual se distribuye bajo la licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0). Usted es libre de compartir y adaptar el material bajo los siguientes términos: debe dar crédito al autor, no puede utilizarlo para fines comerciales y debe compartir las obras derivadas bajo la misma licencia. La licencia completa está disponible en https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode.es.
La autenticación mediante firma digital (o clave pública) es el método más seguro y recomendado para acceder a servidores SSH. Sustituye por completo el uso de contraseñas, eliminando el riesgo de ataques de fuerza bruta y ofreciendo una verificación criptográfica robusta de la identidad tanto del cliente como del servidor.
Este manual asume que ha leído y configurado los aspectos básicos tratados en el documento Configuración de OpenSSH, y lo guiará desde la generación de sus claves hasta la implementación de este método de autenticación, incluyendo procedimientos para gestión y respuesta a emergencias.
Este método se basa en un par de claves criptográficas matemáticamente relacionadas: una clave privada (que debe guardarse en secreto absoluto) y una clave pública (que puede distribuirse libremente).
~/.ssh/authorized_keys en el servidor. Actúa como un candado que sólo su llave privada puede abrir.La autenticación ocurre cuando el servidor desafía al cliente a demostrar que posee la clave privada correspondiente a la clave pública registrada, sin transmitirla nunca. Este método es inmune a ataques de adivinación de contraseña.
Existen dos enfoques principales para gestionar las claves en múltiples servidores. Esta sección analiza las ventajas de cada uno para ayudarle a tomar una decisión informada según su entorno.
La decisión final depende del modelo de seguridad de su organización, pero para administradores individuales y entornos educativos, una clave fuerte y bien protegida ofrece el mejor equilibrio entre seguridad y practicidad.
La generación de una clave segura es el primer paso. El algoritmo elegido determina la fortaleza criptográfica y la compatibilidad con sistemas heredados.
Abra un intérprete de mandatos y ejecute ssh-keygen. Se recomienda enfáticamente el algoritmo Ed25519 por su seguridad, rendimiento y huellas más cortas. Si requiere compatibilidad con sistemas muy antiguos que carecen de soporte para Ed25519, utilice RSA con al menos 4096 bits.
Para Ed25519 (Recomendado):
ssh-keygen -t ed25519 -C "comentario para identificar esta clave (ej: correo o equipo)"
Para RSA (Compatibilidad de legado):
ssh-keygen -t rsa -b 4096 -C "comentario para identificar esta clave (ej: correo o equipo)"
El asistente le preguntará:
~/.ssh/id_ed25519 o ~/.ssh/id_rsa).Ejemplo de una sesión completa:
$ ssh-keygen -t ed25519 -C "darkshram@estacion-principal"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/usuario/.ssh/id_ed25519): <Enter>
Enter passphrase (empty for no passphrase): <Ingrese una frase segura aquí>
Enter same passphrase again: <Repita la frase>
Your identification has been saved in /home/usuario/.ssh/id_ed25519
Your public key has been saved in /home/usuario/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:jX3gF8LmTk5P/9rSw1n6aBcDZ7YqWxOoVpLlM2nHbP0 darkshram@estacion-principal
The key's randomart image is:
+--[ED25519 256]--+
| .o. |
| . + . |
| + o |
| . = . |
| . +S+ |
| . o.* . |
| . .+=.+ |
| .+=E+. |
| .++=OO |
+----[SHA256]-----+
PuTTY carece de una implementación nativa de OpenSSH, por lo que debe utilizar sus propias herramientas: PuTTYgen para generar claves y Pageant para gestionarlas.
.ppk (formato propio de PuTTY). Este es su archivo de clave privada.ssh-ed25519 AAA... o ssh-rsa AAA... hasta el comentario). Puede guardarlo también en un archivo de texto usando el botón "Save public key", pero note que PuTTY lo guarda en un formato distinto; el texto copiado es el que necesita.Con su par de claves generado, el siguiente paso es autorizar el acceso copiando la clave pública al servidor y configurando el servicio SSH para aceptarla.
Método preferido (desde Linux/macOS): Use la herramienta ssh-copy-id. Sustituya usuario y servidor por sus datos. Si su servidor SSH utiliza un puerto distinto al 22, añada -p <puerto>.
ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@servidor
Se le pedirá la contraseña del usuario en el servidor por última vez. Tras introducirla, su clave pública se añadirá automáticamente al archivo ~/.ssh/authorized_keys del usuario remoto.
Método manual (funciona en cualquier sistema): Si carece de ssh-copy-id o está en Windows, debe añadir manualmente el contenido de su archivo .pub (o el texto copiado de PuTTYgen) al final del archivo ~/.ssh/authorized_keys en el servidor. Puede hacerlo con un editor como vim o mediante un mandato:
# En su estación LOCAL, muestre su clave pública y cópiela
cat ~/.ssh/id_ed25519.pub
# Luego, en el SERVIDOR (conéctese con su contraseña aún), ejecute:
mkdir -p ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKl... (pegue aquí el contenido completo)" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
La autenticación por clave suele estar activada por defecto. Verifique o edite el archivo /etc/ssh/sshd_config en el servidor para confirmar:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Acceso a root con clave (Práctica desaconsejada): Si por una razón de fuerza mayor debe permitir acceso SSH directo a root, jamás combine PermitRootLogin yes con contraseñas. El valor más restrictivo posible es:
PermitRootLogin prohibit-password
Esto sólo permitirá el acceso a root mediante autenticación por clave pública. Se recomienda encarecidamente deshabilitar el acceso directo a root (PermitRootLogin no) y utilizar sudo para tareas privilegiadas, como se explica en el manual de Configuración y uso de sudo.
Reinicie el servicio sshd para aplicar los cambios. Use el mandato correspondiente a su sistema de inicio:
systemctl restart sshdservice sshd restartLuego, verifique que la configuración activa sea la correcta con el mandato de prueba:
sshd -T | grep -E "(pubkeyauthentication|permitrootlogin)"
Con la clave implementada, es momento de probar la conexión. Si estableció una frase de acceso, se le pedirá una vez por sesión.
ssh usuario@servidor
Para evitar escribir la frase de acceso en cada conexión, puede usar el agente SSH (ssh-agent), que mantiene sus claves desbloqueadas en memoria durante su sesión.
ssh-agent suele iniciarse automáticamente. Para añadir su clave, ejecute ssh-add. Se le pedirá su frase de acceso una vez.Pageant. Ejecútelo, haga clic con el botón derecho en su icono en la bandeja del sistema, seleccione "Add Key" y elija su archivo .ppk. Ingrese su frase de acceso.Una vez en funcionamiento, es importante saber cómo identificar, revisar y revocar claves para mantener un entorno seguro y ordenado.
Para conocer el algoritmo, longitud y huella de una clave pública (más allá de su nombre de archivo), utilice:
ssh-keygen -l -f ~/.ssh/id_ed25519.pub
La salida será similar a: 256 SHA256:jX3gF8LmTk5P/9rSw1n6aBcDZ7YqWxOoVpLlM2nHbP0 comentario (ED25519). Esto le indica que es una clave ED25519 de 256 bits.
Si ya no desea que una clave específica tenga acceso al servidor, debe eliminarla del archivo ~/.ssh/authorized_keys en dicho servidor. Edite el archivo y borre la línea completa correspondiente a esa clave.
Para mayor precisión, puede usar el mandato sed si conoce una parte única del comentario de la clave:
sed -i '/patron-de-comentario/d' ~/.ssh/authorized_keys
Reemplace patron-de-comentario por un texto único que identifique la línea a borrar (ej: el correo electrónico usado en el comentario).
Si sospecha que su clave privada pudo haber sido robada o comprometida, siga este procedimiento de emergencia para rotar sus credenciales de inmediato. Copie y pegue el siguiente bloque en un intérprete de mandatos, sustituyendo las variables según corresponda.
#!/bin/bash
# PROCEDIMIENTO DE EMERGENCIA - ROTACIÓN DE CLAVE SSH
# 1. Defina las variables siguientes:
USUARIO="su_usuario_en_el_servidor"
SERVIDOR="ip.o.nombre.del.servidor"
PUERTO_SSH="22" # Cámbielo si usa un puerto personalizado
# 2. Generar un nuevo par de claves LOCAL (Ed25519)
echo "Generando nueva clave de emergencia (Ed25519)..."
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_emergencia -N "" -C "emergencia-$(date +%Y%m%d)"
# 3. Copiar la nueva clave pública al servidor (se pedirá la contraseña DEL USUARIO)
echo "Copiando nueva clave al servidor $SERVIDOR..."
ssh-copy-id -i ~/.ssh/id_ed25519_emergencia.pub -p $PUERTO_SSH $USUARIO@$SERVIDOR
# 4. Conectarse al servidor con la NUEVA clave y eliminar la clave pública VIEJA (ASUMIENDO que la vieja era id_ed25519[.pub])
echo "Conectándose para revocar la clave anterior..."
ssh -i ~/.ssh/id_ed25519_emergencia -p $PUERTO_SSH $USUARIO@$SERVIDOR "sed -i '/^ssh-ed25519.*id_ed25519$/d' ~/.ssh/authorized_keys"
echo "Rotación de emergencia completada."
echo "Nueva clave privada: ~/.ssh/id_ed25519_emergencia"
echo "Recuerde distribuir esta nueva clave a sus otras estaciones y ELIMINAR la clave comprometida de forma segura."
Instrucciones post-emergencia:
/var/log/secure) en busca de accesos no autorizados.shred -u) los archivos de la clave antigua comprometida.Para elevar aún más la seguridad, puede deshabilitar algoritmos de intercambio de claves (kex) y cifrado considerados débiles o legacy. Añada las siguientes líneas a su /etc/ssh/sshd_config:
# Preferir algoritmos modernos y seguros
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
Advertencia: Esta configuración puede ser incompatible con clientes SSH muy antiguos. Reinicie el servicio tras realizar estos cambios.
Incluso con una configuración correcta, pueden surgir inconvenientes. Esta sección aborda los problemas más frecuentes al implementar la autenticación por clave.
Error "Permission denied (publickey)":
~/.ssh debe ser 700 y ~/.ssh/authorized_keys debe ser 600.authorized_keys.sshd_config esté PubkeyAuthentication yes.El agente SSH olvida mi frase de acceso:
eval $(ssh-agent) y luego ssh-add para cargar su clave en una sesión nueva.PuTTY rechaza la clave privada:
.ppk correcto en Pageant o seleccionándolo en la configuración de conexión de PuTTY (Connection > SSH > Auth).authorized_keys en formato OpenSSH (el que copió de PuTTYgen), no en el formato por defecto de "Save public key" de PuTTYgen.Ha implementado la autenticación por clave pública, eliminando el vector de ataque más común contra SSH. Recuerde que la seguridad es un proceso en capas: combine este método con las prácticas del manual de configuración base, como cambiar el puerto predeterminado y usar AllowUsers, y considere integrar un sistema como Fail2Ban para proteger contra intentos de acceso persistentes.
Mantenga su clave privada y su frase de acceso a salvo, revíselas periódicamente y tenga siempre a mano el procedimiento de emergencia para actuar con rapidez.