Paralelos con SSH Estándar

SSH estándar con llaves de usuario:

• Flujo de trabajo: Los usuarios generan pares de llaves; los admins agregan manualmente las públicas a ~/.ssh/authorized_keys en cada servidor.
• Pros: Elimina contraseñas; criptografía fuerte; funciona offline.
• Contras: Pesadilla de escalabilidad; agregar/quitar usuarios requiere tocar cada servidor; no hay expiración automática ni restricciones; llaves comprometidas quedan hasta que se limpien manualmente; trazabilidad de auditoría limitada a logs.

SSH estándar con contraseñas:

• Flujo de trabajo: Los usuarios se autentican con contraseñas almacenadas en servidores (a menudo hasheadas).
• Pros: Configuración cero para usuarios; simple de implementar.
• Contras: Susceptible a ataques de fuerza bruta; las contraseñas débiles son comunes; no hay auditoría de logins exitosos; las contraseñas se pueden pezcar o reusar; los cambios de contraseña centralizados son propensos a errores.

Certificados SSH:

• Flujo de trabajo: CA firma llaves en credenciales portátiles y es rica en políticas.
• Mejor que llaves de usuario: Emisión/revocación centralizada; los certificados expiran automáticamente; opciones para restricciones de comando/IP; auditoría más fácil vía IDs de llaves y seriales.
• Mejor que contraseñas: Criptográficamente fuerte; sin secretos compartidos; soporta multi-factor (ej. con FIDO); amigable a la auditoría.
• Peor que ambos: Complejidad inicial de configuración de CA; llave privada de CA es un punto único de fallo (si se compromete, todos los certificados son inválidos; a rótarla inmediatamente); requiere soporte de OpenSSH; no es compatible con clientes/servidores SSH viejos.

En resumen, los certificados brillan para organizaciones que necesitan autenticación escalable y manejado con políticas. Para uso personal o despliegues pequeños, las llaves tradicionales suelen bastar.

Cómo Funcionan los Certificados SSH

Un certificado SSH es una extensión firmada por una llave pública, que contiene:

• Llave pública: La llave del usuario/host siendo certificada.
• ID de llave: Un identificador legible a humanos (ej. "juan@empresa").
• Principals: Usuarios permitidos (para certificados de usuario) o hostnames (para certificados de host).
• Opciones: Permisos/restricciones (por ejemplo. "no-port-forwarding").
• Período de validez: Fechas de inicio/fin para una expiración automática.
• Número serial: ID único para revocación.
• Firma de CA: Prueba autenticidad.

Los servidores checan la llave pública de la CA para verificar firmas, eliminando el almacenamiento por usuario de llaves. Los certificados son portátiles y auto-contenidos.

Prerrequisitos

• OpenSSH 7.0+ (los certificados fueron introducidos en la v5.4, pero lo acabaron hasta la v7.0). En Fedora 43, viene instalado por defecto (openssh-10.0p1-5.fc43.x86_64 al momento).
• Acceso a una máquina segura para operaciones de CA (idealmente offline).
• Conocimiento básico de generación de llaves SSH.

Generando una llave de CA

La llave de CA es la base; su parte privada firma todos los certificados, así que protéjala fiéramente.

Elige un tipo de llave fuerte (ed25519 recomendado por velocidad/seguridad):

ssh-keygen -t ed25519 -f ca_key -C "SSH CA para ejemplo.tld"

Esto crea ca_key (privada; nunca la compartas) y ca_key.pub (pública; distribúyela entre los servidores y clients).

Para RSA (si ed25519 no está soportado):

ssh-keygen -t rsa -b 8192 -f ca_key -C "SSH CA para ejemplo.tld"

Creando Certificados de Usuario

Los certificados de usuario permiten a usuarios autenticarse en servidores sin agregar llaves individualmente. Vamos paso a paso, empezando con lo básico y agregando funcionalidad para hacerlo más seguro y flexible. Así es más fácil entender qué hace cada opción.

Paso 1: Certificado Básico

Primero, genera la llave del usuario si no tienes una:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "juan@ejemplo.tld"

Ahora, firma la llave pública con la CA para crear un certificado básico. La opción -s especifica la llave privada de la CA, -I es la identidad (un ID legible para identificar el cert), y -z es un número de serie único para evitar colisiones.

ssh-keygen -s ca_key -I "juan@ejemplo.tld" -z 1 ~/.ssh/id_ed25519.pub

Esto crea ~/.ssh/id_ed25519-cert.pub, un certificado válido para cualquier usuario en cualquier host que confíe en la CA. Básico pero funcional.

ssh-keygen -s ca_key -I "juan@ejemplo.tld" -n juan,respaldo -z 2 ~/.ssh/id_ed25519.pub

ssh-keygen -s ca_key -I "juan@ejemplo.tld" -n juan,respaldo -O no-port-forwarding -O no-agent-forwarding -z 3 ~/.ssh/id_ed25519.pub

ssh-keygen -s ca_key -I "juan@ejemplo.tld" -n juan,respaldo -O no-port-forwarding -O no-agent-forwarding -V +30d -z 4 ~/.ssh/id_ed25519.pub

ssh-keygen -s ca_key -I "respaldo@ejemplo.tld" -n respaldo -O force-command="/usr/bin/rsync --server --daemon" -V +1d -z 5 ~/.ssh/id_ed25519.pub

ssh-keygen -s ca_key.pub -D /usr/lib/opensc-pkcs11.so -I "juan@ejemplo.tld" -z 6 ~/.ssh/id_ed25519.pub

ssh-add ca_key
ssh-keygen -Us ca_key.pub -I "juan@ejemplo.tld" -z 7 ~/.ssh/id_ed25519.pub

Creando Certificados de Host

Los certificados de host prueban identidad de servidor a clients, previniendo ataques MitM.

Pasos (corre en cada host):

1. Genera llaves de host (si no están presentes; especifica tipo para evitar clutter):

   sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
   

   Nota

   Seguramente, esto lo hace tu distribución. En Fedora 43, lo hace un servicio llamado sshd-keygen, el cual corre siempre al iniciar y genera la llave de host si esta no existe. Te genera 3, de hecho.

2. Firma básica:

   ssh-keygen -s ca_key -I "web01.ejemplo.tld" -h -z 1001 /etc/ssh/ssh_host_ed25519_key.pub
   

   Output: /etc/ssh/ssh_host_ed25519_key-cert.pub.

3. Limita a los principals (hostnames e IPs para que sea más robusto):

   ssh-keygen -s ca_key -I "web01.ejemplo.tld" -h -n web01.ejemplo.tld,web01,10.0.0.5 -z 1002 ~/.ssh/ssh_host_ed25519_key.pub
   

4. Determina la validez:

   ssh-keygen -s ca_key -I "web01.ejemplo.tld" -h -V 20240101:20241231 -z 1003 /etc/ssh/ssh_host_ed25519_key.pub
   

Revocando Certificados

Usa "Key Revocation Lists (KRLs)" para invalidar certificados comprometidos. Siempre usa seriales únicos (-z) para una revocación efectiva.

1. Crea KRL (por archivo de certificado):

   ssh-keygen -k -f revoked.krl ~/.ssh/id_ed25519-cert.pub
   

2. Actualiza KRL (agrega otro con el certificado):

   ssh-keygen -k -u -f revoked.krl another-cert.pub
   

3. Revoca por Serial (no necesitas el certificado):

   ssh-keygen -k -u -f revoked.krl -s ca_key -z 10
   

4. Distribuye KRL a servidores (ej. via config):

   En /etc/ssh/sshd_config:

   RevokedKeys /path/to/revoked.krl
   

5. Checa la revocación:

   # Exit != 0 si fue revocado
   ssh-keygen -Q -f revoked.krl ~/.ssh/id_ed25519-cert.pub
   

Configurando Confianza

La confianza se configura para que servidores y clientes reconozcan la CA y verifiquen certificados. Sin esto, los certificados son papel mojado; el servdor rechaza logins porque no confía en la firma de la CA. La neta, es como darle una carta de recomendación a alguien que no conoce al firmante. Vamos por partes, compa, para que quede clarito.

Ejemplos

Ejemplo 1: Certificado de Usuario Básico

• Escenario: Acceso estándar de usuario.

  ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
  
  ssh-keygen -s ca_key -I "pancho@empresa" -z 10 ~/.ssh/id_ed25519.pub
  
  # Distribuye ca_key.pub a servidores
  # Login: ssh pancho@servidor
  

Ejemplo 2: Usuario de Backup Restringido

• Escenario: Rsync automatizado con límites de IP/comando. (Nota: source-address puede ser frágil en entornos cloud dinámicos.)

  ssh-keygen -s ca_key -I "respaldo@servidor" -n respaldo -O force-command="/usr/bin/rsync --server" -O source-address="10.0.0.0/8" -V +1d -z 11 ~/.ssh/id_ed25519.pub
  

Ejemplo 3: Certificado de Host para Cluster

• Escenario: Nodos de cluster seguros. (Flujo seguro: Trae llaves a máquina CA, firma localmente, despliega certificados.)

  for host in node1 node2; do
    # Copia la llave de host a la máquina CA segura
    scp $host:/etc/ssh/ssh_host_ed25519_key.pub /tmp/$host.pub
  
    # Firma localmente con CA
    ssh-keygen -s ca_key -I "$host.cluster" -h -z 1004 /tmp/$host.pub
  
    # Despliega certificado de vuelta
    scp /tmp/$host-cert.pub $host:/etc/ssh/ssh_host_ed25519_key-cert.pub
  done
  
  # Los clientes agregan @cert-authority a known_hosts
  

Ejemplo 4: Certificado de Usuario FIDO

• Escenario: Llaves por hardware.

  ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk
  ssh-keygen -s ca_key -I "juan@fido" -z 12 ~/.ssh/id_ecdsa_sk.pub
  

Ejemplo 5: Certificado con Extensiones

• Escenario: Opciones custom.

  ssh-keygen -s ca_key -I "dev@team" -O critical:source-address="192.168.1.0/24" -O extension:permit-pty -z 13 ~/.ssh/id_ed25519.pub
  

Ejemplo 6: Inspeccionando Certificados

• Ver detalles:

  ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub
  

Ejemplo 7: Revocando un Certificado

• Agrega a KRL y despliega:

  ssh-keygen -k -u -f revoked.krl ~/.ssh/id_ed25519-cert.pub
  scp revoked.krl server:/etc/ssh/
  

Mejores Prácticas y Consideraciones de Seguridad

• Seguridad de la llave privada del CA: Guarda la llave privada del CA en algún lugar seguro. Nunca las uses en servidores de producción. Rota las CAs anualmente o en caso de compromiso; usa una CA dual: Agrega ambas partes públicas de las llaves de la CA vieja y nueva a TrustedUserCAKeys durante transición para evitar lockouts.

• Períodos de Validez: Usa ciclos de vida cortos (días/semanas) para certificados de usuario y más largos para los hosts (meses/años). Automatiza la renovación.

• Auditoría: Log uso de certificados via sshd; monitorea anomalías.

• Integración: Automatiza con Ansible o Chafánsible la distribución de certificados. Un rol de ejemplo con Ansible:

  - name: Despliega llave pública del CA
    copy:
      content: "{{ ca_pub_key }}"
      dest: /etc/ssh/ca.pub
    notify: reload sshd
  

• Evita errores comunes: No firmes certificados con opciones débiles; prueba la revocación; usa ed25519.

Automatización y Escalado

Para despliegues grandes, evita exponer llaves privadas del CA. Usa herramientas seguras:

• Firmado manual con script (solo en máquina CA segura):

  #!/usr/bin/bash
  
  # ssh-signer.bash - Corre en la máquina con el CA
  user=$1
  key=$2
  serial=$( date +%s%N )  # Serial único basado en timestamp
  
  ssh-keygen -s ca_key -I "$user" -V +7d -O no-port-forwarding -z "$serial" "$key"
  

• Certificados de Host en bola: Para inicializar, usa OpenTofu para injectar la llave pública del CA. Para sconfigurarlo manualmente:

  serial=$( date +%s%N )  # Serial único basado en timestamp
  
  for host in $(cat hosts.txt); do
    scp $host:/etc/ssh/ssh_host_ed25519_key.pub /tmp/$host.pub
    ssh-keygen -s ca_key -I "$host" -h -z $serial /tmp/$host.pub
    scp /tmp/$host-cert.pub $host:/etc/ssh/ssh_host_ed25519_key-cert.pub
  done
  

• Monitoreo: Usa ssh-audit o scripts custom para verificar certificados.

Conclusión

Los certificados SSH lo transforman de un protocolo simple en un sistema de autenticación robusto. Centralizando confianza y habilitando políticas, se ofrece escalabilidad y seguridad sin par. Empieza en chiquito, prueba con un usuario/host; luego escala. Recuerda, la CA es tu joya de la corona; protéjala.

RTFM!

• man ssh-keygen
• man sshd_config
• docs oficiales de OpenSSH: https://www.openssh.org/manual.html
• RFC 4251: https://datatracker.ietf.org/doc/html/rfc4251

Contribuye mejoras en:

https://github.com/openssh/openssh-portable

¡Chido, ahora ve y securiza tus despliegues!