MFA para SSH: YubiKey, PAM‑FIDO2, Jump‑Hosts y estrategias pragmáticas de contingencia para acceso administrativo

Un acceso de administración remota seguro es un requisito básico para un funcionamiento fiable. MFA para SSH, es decir, la combinación de clave pública y un segundo factor (p. ej. FIDO2/YubiKey), reduce de forma significativa el riesgo de contraseñas comprometidas o de SSH‑Keys robados. En este artículo explico cómo funciona la técnica, qué componentes (YubiKey‑Resident‑Keys, PAM‑FIDO2, OpenSSH, Jump‑Hosts) intervienen, qué trampas y riesgos suelen aparecer y cómo planificar estrategias de recuperación reales para emergencias. El público objetivo son administradores, System Engineers y equipos de operación que buscan procedimientos seguros y prácticos.

¿Qué significa MFA para SSH y por qué es importante?

MFA (Multi‑Factor Authentication) es un principio de autenticación con al menos dos factores diferentes: algo que el usuario posee (p. ej. un YubiKey) y algo que conoce o tiene (p. ej. una clave SSH privada o una contraseña). Para SSH suele significar: autenticación por clave pública más FIDO2/U2F‑Touch o una segunda etapa basada en PAM. El beneficio es concreto: incluso si se ha exfiltrado una clave SSH privada, la ausencia del token físico impide el acceso.

MFA para SSH: Kernelemente und Varianten

OpenSSH con FIDO2‑Resident‑Keys

OpenSSH soporta desde versiones recientes tipos de clave como ed25519-sk, que utilizan tokens FIDO2. Los Resident Keys son claves privadas almacenadas directamente en el token. Esto sustituye a los archivos de clave locales y obliga al Touch/PIN al usar el token. La desventaja es la dependencia del ciclo de vida del token: planifique procedimientos de reemplazo y recuperación.

# Resident FIDO2‑Key erstellen (speichert Key auf Token, verlangt Touch beim späteren Login)
ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk

PAM‑FIDO2 como segundo factor central

PAM (Pluggable Authentication Modules) ist das modulare Authentifizierungssystem unter Linux. Un módulo PAM‑FIDO2 (p. ej. pam_fido2 o libpam-u2f) puede integrarse en /etc/pam.d/sshd para forzar, además del Publickey, una segunda autenticación en los inicios de sesión SSH. PAM es potente, pero una configuración errónea puede impedir por completo los accesos: por eso primero pruebe en un entorno aislado.

# Minimaler relevanter Ausschnitt von /etc/ssh/sshd_config
PubkeyAuthentication yes
ChallengeResponseAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive

# Beispiel‑PAM‑Snippet in /etc/pam.d/sshd (schematisch)
auth    required    pam_fido2.so debug
account required    pam_nologin.so

Importante: el parámetro AuthenticationMethods obliga a OpenSSH a requerir primero la clave pública y luego desencadenar PAM (keyboard‑interactive), que a su vez realiza la comprobación FIDO2. Ordenes incorrectas o módulos faltantes provocan «lockouts».

Certificados SSH como complemento

Los certificados SSH son firmas emitidas por una CA interna para claves públicas SSH. Simplifican la revocación y permiten controlar centralmente la validez. Como complemento a MFA, permiten conceder accesos con validez temporal sin distribuir archivos en los dispositivos de los usuarios —ideal para accesos de emergencia temporales.

# CA-Schlüssel erzeugen (auf geschütztem CA‑Host)
ssh-keygen -t ed25519 -f /root/ssh_ca_key -N ""
# Benutzer-Öffentlichen Schlüssel signieren (z. B. 1 Stunde gültig)
ssh-keygen -s /root/ssh_ca_key -I emergency -n admin -V +1h user.pub

Jump‑Hosts und Bastion‑Architektur: zentral für MFA‑Betrieb

Un Jump‑Host (Bastion Host) es un punto de acceso controlado a un segmento protegido. Reduce la superficie de ataque y permite autenticación centralizada, registro de sesiones y control de accesos. Principios operativos importantes:

• Asegure el Jump‑Host: pila de software mínima, reglas de firewall estrictas, cuentas de usuario restringidas.
• Implemente MFA de forma obligatoria en el Jump‑Host; solo deberían permitirse conexiones a hosts productivos a través de la bastión.
• Registro de sesiones y auditoría: complemente con registros (p. ej. tty‑recording o auditd) para trazabilidad forense.

# ProxyJump-Verwendung (Admin‑Workstation → Bastion → Zielhost)
ssh -J bastion.example.com admin@internal-host.example.net

El Agent Forwarding debería estar desactivado en general, porque permite a un atacante, a través de una máquina objetivo comprometida, explotar el agente. Actívelo a nivel de estación de trabajo solo de forma selectiva para sesiones de confianza.

Configuración práctica de PAM y tokens: ejemplos y comprobaciones

El mapeo PAM para FIDO2 varía según el módulo. Es habitual una archivo de mapeo que asocia un identificador de token a una UID Unix. Los ejemplos ayudan a localizar posibles fuentes de error.

# Beispiel: /etc/u2f_mappings (schematisch)
# token_hex_serial:username
1234567890abcdef:alice
fedcba0987654321:bob

# Benutzerseitige Debug‑Tools
# Prüfen, ob Token erkannt wird
ssh -v -i ~/.ssh/id_ed25519_sk alice@bastion.example.com
# PAM-Debug-Logs (auf dem Zielhost)
sudo journalctl -u sshd -f

Al probar tenga en cuenta: los módulos PAM a menudo escriben sus propios logs de depuración; active el modo debug solo temporalmente para evitar que información sensible permanezca de forma permanente en los archivos de registro.

Plan de despliegue: piloto a producción

Un despliegue estructurado y por fases minimiza las interrupciones operativas:

1. Piloto: 2–5 administradores, entorno aislado de Jump‑Host de pruebas y lista de verificación de pruebas completa.
2. Ampliación: inclusión del equipo de operaciones, KPI de logging y ejercicios de contingencia.
3. Producción: despliegue a nivel organizacional, formación, procesos de incorporación y baja operativizados.

Durante la fase piloto debe probarse de forma sistemática:

• Generación y uso de Resident Keys.
• Escenarios de fallo de PAM (token defectuoso, error de PIN) y las entradas de log asociadas.
• Escenarios de respaldo (Break‑Glass, certificados SSH temporales, consola OOB).

Estrategias de contingencia en detalle — planes, listas de verificación y automatización

Una estrategia de contingencia evita que un token perdido o un problema de PAM paralice la operación. Los buenos planes de contingencia son escalonados y están documentados.

Break‑Glass: flujo del proceso

Una cuenta Break‑Glass es una identidad de emergencia estrictamente controlada. Propuesta de flujo y medidas técnicas:

• Mantener una cuenta Break‑Glass por servicio crítico, protegida por copia física de la llave (en caja fuerte) o certificado con validez temporal.
• Antes del uso: aprobación mediante un proceso definido de múltiples ojos (p. ej. segunda firma en el sistema de tickets) y rotación automática de la contraseña tras su uso.
• Cada uso se audita automáticamente y desencadena una cadena de alarmas (pager/SMS/email) al equipo de respuesta a incidentes.

Certificados SSH temporales mediante Signing‑Service

Un Signing‑Service automático (herramienta interna con RBAC) puede emitir certificados a corto plazo cuando faltan tokens. Implemente pasos de auditoría y periodos de validez cortos (p. ej. 15–60 minutos). Un signer sencillo controlado por systemd con Auth‑Hooks suele ser suficiente.

# Beispiel: temporäres Zertifikat (1h Gültigkeit)
ssh-keygen -s /root/ssh_ca_key -I emergency -n admin -V +1h user.pub
# Gültigkeit prüfen (lokal):
ssh-keygen -L -f user-cert.pub

Acceso OOB físico y consola

Out‑of‑Band (IPMI/Redfish, Konsolenserver) no debe solo existir, sino también estar endurecido y probarse regularmente. OOB garantiza que tenga acceso incluso si los servicios SSH o las autenticaciones fallan. Reglas:

• Aislar físicamente/lógicamente las redes OOB.
• Permitir el acceso a OOB solo a través de Admin‑VMs protegidas con MFA.
• Aplicar parches al firmware regularmente y eliminar las credenciales por defecto.

Comprobaciones concretas de resolución de problemas

Si el inicio de sesión falla, una depuración sistemática conduce rápidamente a la causa. Secuencia de ejemplo:

1. SSH en modo verbose en la estación de trabajo: ssh -vvv comprobar si se ofrece la clave sk.
2. Comprobar los registros del servidor: sudo journalctl -u sshd -b o /var/log/auth.log.
3. Probar temporalmente los módulos PAM con un contexto PAM separado o en un host de pruebas.
4. Comprobar el estado del token: ¿está dañado el token? ¿Se han excedido los intentos de PIN?

# Beispielbefehle
# Debug auf Client
ssh -vvv -i ~/.ssh/id_ed25519_sk alice@bastion.example.com
# Server logs
sudo journalctl -u sshd -n 200
# Suche nach FIDO‑Fehlern
sudo journalctl -u sshd | grep -i fido || sudo grep -i fido /var/log/auth.log

Gestión del ciclo de vida de los tokens

El ciclo de vida de los tokens comprende emisión, reemplazo, bloqueo y eliminación. Gestione los tokens de forma centralizada con inventario, responsabilidades y ventanas temporales:

• Emisión: Entrega documentada con firma y referencia de ticket (p. ej., número de ticket de Zammad).
• Reemplazo: Proceso estándar para tokens dañados o que no responden; emisión de un certificado temporal para reprovisionamiento.
• Bloqueo: En caso de pérdida, marcar inmediatamente el token como comprometido y revocar los certificados SSH correspondientes y los bindings PAM asociados.
• Eliminación: Borrar los tokens de forma segura (si es posible) y destruirlos físicamente cuando sean retirados.

Para la automatización puede usar YubiKey Manager CLI (ykman) para consultar información de números de serie y de los slots configurados. Tenga en cuenta, sin embargo, que no todos los modelos de token admiten exactamente los mismos comandos.

# YubiKey Manager: Seriennummer anzeigen
ykman info

Integración en servicios de directorio y CI/CD

En entornos grandes, los administradores a menudo se autentican contra LDAP/AD. PAM‑FIDO2 puede operar en paralelo con enlaces LDAP: LDAP proporciona la información de cuentas y PAM‑FIDO2 valida el segundo factor. Preste atención al orden en /etc/pam.d/sshd para que las comprobaciones de cuenta LDAP no bloqueen PAM‑FIDO2.

Las ejecuciones de CI/CD y las automatizaciones no deben depender de tokens físicos. Use Machine‑Accounts para los trabajos de pipeline con certificados SSH o claves de host que se gestionen de forma centralizada y tengan limitación temporal. Almacene los secretos en Vaults y rote las credenciales regularmente.

Errores comunes y cómo evitarlos

• Configuraciones PAM defectuosas: pruebe siempre con una cuenta de administración separada y tenga disponible una consola OOB.
• Modelos de token incompatibles: no todos los tokens FIDO2 soportan Resident Keys; verifique la matriz de hardware antes de comprar.
• USB‑Passthrough en escritorios virtuales: a veces los tokens no se reenvían de forma fiable; pruebe en los entornos de sus usuarios.
• Reenvío de agente: desactive el reenvío de agente, ya que puede socavar la protección MFA en la estación de trabajo.

Indicaciones específicas para los equipos de operación de Zammad

Las instancias de Zammad suelen requerir roles de acceso diferenciados: desarrolladores, responsables de la aplicación, administradores de BD. Recomendaciones aplicadas de forma práctica:

• Ejecute las tareas administrativas específicas de Zammad únicamente a través de la bastión y separe las sesiones de DB‑Admin de los despliegues de la aplicación.
• Registre las asignaciones de tokens y los eventos Break‑Glass directamente en el sistema de tickets (p. ej. Zammad), de modo que se conserven los audit‑trails y el contexto de cambios.
• Para la recuperación ante desastres, mantenga un procedimiento que establezca cómo se concede el acceso a la base de datos con permisos mínimos y certificados temporales —documentado en el Disaster‑Recovery‑Runbook.

{
  "ticket_type": "Break-Glass",
  "summary": "Temporärer Zugang: CA-Zertifikat ausstellen",
  "requested_by": "alice",
  "approver": "operations_lead",
  "reason": "Verlorener YubiKey",
  "issued_certificate_ttl": "60m",
  "audit_note": "Certificate issued per emergency procedure"
}

Lista de verificación para producción (breve)

• Realice un piloto con 2–5 administradores y documente las lecciones aprendidas.
• Endurezca el jump‑host, implemente MFA de forma obligatoria y desactive el Agent Forwarding.
• Configure certificados SSH temporales y pruebe el Signer‑Service.
• Defina cuentas Break‑Glass, implemente el flujo de aprobación y active la auditoría.
• Verifique los accesos OOB y realice ejercicios de emergencia semestrales.

Conclusión y recomendaciones de actuación

MFA para SSH con YubiKey y PAM‑FIDO2 es una medida práctica que hace el acceso administrativo claramente más seguro. Lo decisivo es un despliegue responsable: grupo piloto, procesos documentados de onboarding/offboarding, estrategias de retorno probadas y registro estricto. Para los equipos de operación de Zammad, además, es necesario separar estrictamente los accesos, documentar las asignaciones de tokens en el sistema de tickets y ensayar los procedimientos de recuperación.

Resumen rápido para llevar:

• Defina un grupo piloto y establezca un entorno de pruebas aislado.
• Pruebe OpenSSH‑sk‑Keys y PAM‑FIDO2 en paralelo y valide los registros.
• Endurezca los jump‑hosts; desactive Agent Forwarding por defecto.
• Implemente y pruebe estrategias de recuperación (Break‑Glass, OOB, certificados temporales).
• Integre el inventario de tokens y los procesos de cambio en el sistema de tickets (p. ej. Zammad) y planifique ejercicios de emergencia regulares.

Si es necesario, es recomendable un taller focalizado para reunir opciones técnicas, roles organizativos y playbooks de emergencia e integrarlos en sus procesos operativos.

Perspectivas operativas: protección de la CA, políticas de fallo y HA del bastión

Además de la autenticación de usuarios, la arquitectura de hardening y operación determina la madurez operativa del MFA‑SSH. Proteja sus SSH‑CA‑Privat‑Keys como material criptográfico de producción: idealmente en un HSM o, al menos, fuera de línea en un host dedicado y asegurado. Establezca un plan de compromiso claro: rotación de claves, recuperación ante emergencias y playbooks de comunicación para el caso de pérdida de una clave.

Las decisiones sobre políticas de fallo son críticas: una caída de PAM puede bien rechazar los inicios de sesión (fail‑closed) o permitir el acceso (fail‑open). Favorezca fail‑closed con rutas de recuperación OOB probadas en lugar de excepciones silenciosas, ya que estas últimas socavan la auditoría y la responsabilidad.

Logre alta disponibilidad de bastión mediante instancias de respaldo activas, grabación centralizada de sesiones y servicios de firmantes distribuidos para certificados SSH. Sincronice únicamente metadatos públicos (CA‑Publickeys, registros de auditoría); las claves privadas permanecen estrictamente aisladas.

Automatice el ciclo de vida de tokens y certificados de emergencia a través de su API de ticketing (p. ej. Zammad) o de su software empresarial personalizado, para conectar emisión, revocación y auditoría de forma ininterrumpida. Vigile métricas: tasa de errores de autenticación, tasas de firmado, latencia PAM y Break‑Glass‑Events — las alertas ante desviaciones son obligatorias.

# Sicherer CA‑Rotation‑Ablauf (vereinfachtes Beispiel)
ssh-keygen -t ed25519 -f /root/ssh_ca_key_new -N ""
cp /root/ssh_ca_key_new.pub /etc/ssh/trusted_user_ca_keys/ca_new.pub
# Signieren und testen, dann swappen
ssh-keygen -s /root/ssh_ca_key_new -I test -n admin -V +5m user.pub

Para este tema también son importantes Pam-Fido2 y Jump-Host. El artículo sitúa estos aspectos de forma comprensible y muestra en qué debe centrarse la operativa diaria.