SSH Keys (Claves SSH Criptográficas)

1. Visión general del concepto y problema sistémico

La autenticación tradicional mediante nombre de usuario y contraseña en servidores remotos presenta fallas arquitectónicas críticas: vulnerabilidad a ataques de fuerza bruta, interceptación en caso de compromiso del canal (man-in-the-middle) y el factor humano (uso de contraseñas débiles o repetidas). Una vez que el puerto 22 se abre al internet público, los botnets generan miles de intentos de adivinanza de contraseñas por minuto.

SSH Keys (Claves SSH Criptográficas) abordan este problema a través de la criptografía asimétrica. El usuario genera un par de claves matemáticamente relacionadas:

• Clave Privada (Private Key): Se almacena exclusivamente en la máquina local del desarrollador en forma cifrada con passphrase y nunca se transmite a través de la red.
• Clave Pública (Public Key): Se coloca en el servidor de destino en el archivo ~/.ssh/authorized_keys.

Durante el apretón de manos, el servidor genera un desafío aleatorio, lo cifra o requiere una firma del cliente utilizando la clave privada. La autenticación se realiza mediante la confirmación matemática de la posesión de la clave privada sin revelar el secreto mismo.

+------------------+                    +--------------------+
|  Cliente local    |                    |  Servidor remoto   |
|  (~/.ssh/id_ed)   |                    |  (~/.ssh/auth_keys)|
+--------+---------+                    +---------+----------+
         |                                        |
         |  1. Solicitud de conexión (User, PubKey)  |
         |--------------------------------------->|
         |                                        | 2. Verificación de la
         |                                        |    existencia de la clave
         |  3. Desafío criptográfico (Nonce)      |
         |<---------------------------------------|
         |                                        |
         | 4. Firma del nonce con la clave privada |
         |--------------------------------------->|
         |                                        | 5. Validación de la firma
         |                                        |    con la clave pública
         |  6. Sesión abierta (Authenticated)     |
         |<---------------------------------------|

2. Taxonomía arquitectónica y modelo mental

Los algoritmos criptográficos para SSH han evolucionado junto con el desarrollo de capacidades computacionales y criptoanálisis:

1. Ed25519 (Edwards-curve Digital Signature Algorithm):
   • Estándar de facto moderno en la industria.
   • Basado en la curva elíptica Curve25519.
   • Longitud de clave: 256 bits.
   • Alta resistencia contra ataques de canal lateral y timing, velocidad de ejecución de operaciones extremadamente rápida.
2. ECDSA (Elliptic Curve Digital Signature Algorithm):
   • Utiliza curvas estandarizadas de NIST (por ejemplo, nistp256 o nistp521).
   • Presenta riesgos potenciales de backdoors en la elección de parámetros del generador de NIST y es críticamente sensible a la calidad del generador de números aleatorios (RNG): repetir un valor aleatorio k revela completamente la clave privada.
3. RSA (Rivest-Shamir-Adleman):
   • Algoritmo clásico basado en la factorización de grandes números primos.
   • Claves de longitud inferior a 2048 bits se consideran comprometidas. El mínimo seguro es de 4096 bits.
   • Clave pública y privada masiva, generación y firma más lentas.
4. FIDO2 / Hardware Security Keys (ed25519-sk / ecdsa-sk):
   • Autenticación hardware a través de tokens físicos (YubiKey).
   • La clave privada se genera y nunca abandona el chip protegido del token; cada sesión SSH requiere un toque físico.

3. Pipeline técnico y mecánica interna

Generación y despliegue de una clave segura

Generación de una clave de producción Ed25519 con un número elevado de rondas de derivación de clave (KDF) para proteger contra ataques de fuerza bruta por GPU:

# Generación de Ed25519 con comentario y 100 rondas de KDF
ssh-keygen -t ed25519 -a 100 -C "admin@production-cluster" -f ~/.ssh/id_ed25519_prod

Copia de la clave pública al servidor remoto:

ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub deploy@vps.internal.net

Estructura de permisos del sistema de archivos Linux

Los permisos incorrectos son la causa del 90% de los fallos en la autenticación SSH (Permission denied (publickey)):

# Máquina local del cliente:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_prod
chmod 644 ~/.ssh/id_ed25519_prod.pub
chmod 600 ~/.ssh/config

# Servidor remoto:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Configuración del cliente (~/.ssh/config)

Para evitar la transmisión de largas banderas de línea de comandos, se utiliza una configuración declarativa del cliente:

Host prod-node-01
    HostName 198.51.100.24
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host bastion-jumphost
    HostName 203.0.113.10
    User gatekeeper
    IdentityFile ~/.ssh/id_ed25519_bastion

Host internal-db
    HostName 10.0.4.15
    User postgres
    ProxyJump bastion-jumphost
    IdentityFile ~/.ssh/id_ed25519_db

4. Escenarios prácticos de ingeniería en producción

01. Acceso sin contraseña para un pipeline CI/CD automatizado

En entornos de GitHub Actions o GitLab CI/CD, el despliegue se realiza automáticamente a través de una clave SSH técnica dedicada. La clave privada se almacena en los Secrets cifrados del repositorio, y la clave pública en el servidor se vincula a un shell restringido o a un comando específico mediante la directiva command="..." en authorized_keys:

command="/usr/local/bin/deploy-webhook.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... ci-deploy-key

Incluso si el secreto de CI/CD se ve comprometido, el atacante solo podrá ejecutar un script de despliegue determinado, no comandos arbitrarios en la terminal.

02. Acceso a nodos de infraestructura aislados a través de Bastion (ProxyJump)

En VPC, bases de datos privadas o servidores de agentes de IA no tienen direcciones IP públicas. El ingeniero se conecta a través de un host intermedio Bastion sin necesidad de exportar la clave privada al Bastion:

ssh -J gatekeeper@bastion.example.com deploy@10.0.1.50

SSH tuneliza el tráfico TCP a nivel de socket a través del nodo proxy, cifrando la sesión con la clave final del servidor de destino (ProxyJump no revela el contenido del tráfico del bastión).

03. Claves hardware FIDO2 para infraestructura Zero Trust

En sistemas fintech de alta carga o regulados, los desarrolladores están obligados a utilizar tokens hardware YubiKey. Se crea una clave del tipo ed25519-sk. Cada acción git push o sesión SSH requiere un toque físico en el sensor del token. Esto elimina completamente la amenaza de robo de claves privadas por parte de infostealers o malware en la computadora portátil del desarrollador.

5. Errores comunes, trampas y seguridad

1. Generación de claves sin Passphrase: Almacenar la clave privada sin una contraseña segura crea una amenaza crítica: cualquier proceso malicioso, script o acceso físico a una computadora portátil desbloqueada permite copiar instantáneamente la clave privada y obtener acceso a toda la infraestructura. Siempre proteja las claves con una contraseña y utilice ssh-agent.
2. Descontrol en authorized_keys: Con el tiempo, el archivo acumula decenas de claves de antiguos desarrolladores o contratistas temporales. La falta de auditoría regular abre puertas traseras. Utilice gestión centralizada de claves a través de Ansible, Teleport, HashiCorp Vault o SSH Certificate Authority (CA).
3. Uso de SSH Agent Forwarding (-A): Habilitar ForwardAgent yes en la configuración global permite a las máquinas remotas acceder a su socket local ssh-agent. Nunca habilite Agent Forwarding de forma global; utilice ProxyJump o ssh-add -c para confirmar cada uso de la clave.