Passkeys y FIDO2 en 2026: cómo migrar de contraseñas

Por qué las contraseñas ya no alcanzan

En 2026 las contraseñas siguen siendo el eslabón más débil de cualquier sistema Linux: se filtran en brechas masivas, se reutilizan entre servicios y dependen de la disciplina del usuario final. El estándar FIDO2/WebAuthn propone un reemplazo radical: autenticación criptográfica ligada al dispositivo del usuario, sin secretos compartidos con el servidor. La contraseña deja de existir como tal.

Este artículo cubre cómo funcionan los passkeys, qué cambia para tu servidor SSH, y qué pasos prácticos puedes dar hoy para migrar sin romper a tus usuarios.

Cómo funciona FIDO2 y WebAuthn

FIDO2 es la combinación de dos protocolos: WebAuthn (la API del navegador que registra y firma) y CTAP2 (el canal entre el navegador y el autenticador físico). Cuando registras una llave, tu dispositivo genera un par de claves Ed25519 o ECDSA P-256: la privada nunca sale del hardware, la pública se queda en el servidor. Cada login genera un challenge firmado criptográficamente que el servidor verifica.

Lo crítico es que el servidor no guarda un secreto derivable: si te roban la base de datos, los atacantes no pueden falsificar firmas. Y como la firma varía en cada login (nonce del servidor), un replay attack es matemáticamente inviable.

Diferencia entre passkey sincronizada y llave física

Una passkey sincronizada vive en iCloud Keychain, Google Password Manager o 1Password, y se replica cifrada entre tus dispositivos. Una llave física FIDO2 (YubiKey, SoloKey, Token2) es un dispositivo USB/NFC dedicado que solo firma cuando está presente. La sincronizada es más cómoda; la física es más resistente a phishing porque no sale del hardware.

Para servidores Linux críticos lo sensato es soportar ambos métodos: passkeys sincronizadas para el día a día del equipo, llaves físicas como segundo factor de recovery y para administradores con privilegios elevados.

Verificar que tu servidor SSH ya soporta FIDO2

OpenSSH 8.2+ incluye soporte nativo para claves FIDO2 (ed25519-sk y ecdsa-sk). Si tu distro tiene openssh-server ≥ 8.2, el servidor ya acepta estas claves sin configuración extra. Para verificar:

ssh -V
# OpenSSH_9.6p1 Ubuntu-3ubuntu13.5, OpenSSL 3.0.13

Si ves versión 8.2 o superior, el binario ya soporta el tipo de clave. La salida OpenSSH_9.x confirma que estás en una versión moderna y no necesitas recompilar nada. Si tu servidor reporta 7.x, planifica una actualización antes de desplegar passkeys porque el daemon rechazará las claves nuevas.

Generar una clave SSH FIDO2 en el cliente

El comando ssh-keygen -t ed25519-sk crea el par de claves. El flag -O resident hace que la clave resida en el autenticador físico (YubiKey) y no en disco:

ssh-keygen -t ed25519-sk -O resident -O verify-required -O write-attestation=/tmp/attest.bin
# Enter file in which to save the key (~/.ssh/id_ed25519_sk): [Enter]
# Enter passphrase (empty for no passphrase): [passphrase]
# Touch your authenticator to authorize key generation

El parámetro -O verify-required obliga a pulsar el botón físico de la llave en cada login, lo que cierra el vector phishing donde un atacante clona tu clave en software. El archivo attest.bin contiene la attestation del autenticador, que certifica el modelo y firmware del fabricante (útil para validar que solo se registran YubiKeys oficiales, por ejemplo). El pin del autenticador se solicita la primera vez y se cachea durante la sesión.

Configurar sshd para aceptar solo claves FIDO2

Para forzar el uso de claves *-sk en administradores específicos, añade una Match Block al final de /etc/ssh/sshd_config.d/ (soportado desde OpenSSH 9.6+, Ubuntu 24.04 / Debian 12 backports):

sudo tee -a /etc/ssh/sshd_config.d/10-fido2.conf > /dev/null << 'EOF'
Match Group admins
    AuthenticationMethods publickey
EOF
sudo sshd -t && sudo systemctl reload ssh

Match Group admins segmenta la política: solo el grupo admins se ve afectado, el resto puede seguir usando contraseña mientras migras. El comando sshd -t valida la sintaxis antes de recargar, así evitas quedarte fuera por un typo. La directiva AuthenticationMethods publickey obliga a este grupo a autenticarse únicamente con clave pública, lo que ya bloquea el camino de contraseña.

Integrar WebAuthn en tu propia aplicación web

Si mantienes un panel interno (Grafana, Nextcloud, WordPress con plugin), el camino más rápido es usar la librería simple-webauthn en el backend y el helper nativo navigator.credentials.create() en el frontend. El flujo de registro:

npm install @simplewebauthn/server
node -e "const swa = require('@simplewebauthn/server'); console.log('v', require('@simplewebauthn/server/package.json').version);"
# v 13.1.2

El servidor genera un challenge aleatorio y lo envía al navegador; el autenticador firma con la clave privada y devuelve attestation. El servidor verifica la firma contra la clave pública almacenada en el primer registro. Versiones ≥ 13.0 de simple-webauthn ya validan el formato CBOR correctamente y rechazan attestation self-reported. El detalle importante es que userVerification: 'required' obliga al autenticador a verificar el usuario (pin o biometría), y eso cierra el vector de clave robada sin pin.

Habilitar passkeys en servicios populares

La mayoría de servicios SaaS que usas ya aceptan passkeys. El procedimiento típico es: cuenta → seguridad → “añadir passkey” → el sistema operativo muestra un diálogo nativo (Touch ID, Windows Hello, clave física) → listo.

# Listar passkeys registradas en GNOME (libsecret + fprint)
fprintd-list $USER
# found 1 device
# Device at /net/reactivated/Fprint/Device/0
#   - enrolled: yes
#   - name: "Integrated Fingerprint Reader"
#   - vendor: 14770

El comando fprintd-list muestra los lectores biométricos que el sistema reconoce, lo cual es útil para diagnosticar por qué un login WebAuthn no ofrece huella aunque tu laptop la tenga. Si no ves ningún dispositivo, el daemon fprintd no está corriendo: instálalo y habilítalo con systemctl enable --now fprintd. En servidores headless este paso no aplica, pero en workstations donde también usas passkeys para sudo o login gráfico, sí.

Migrar usuarios sin romper nada

El patrón recomendado es mantener contraseña + llave durante una ventana de transición de 30 a 90 días, y luego deshabilitar contraseña por grupo. En SSH el equivalente es:

sudo tee /etc/ssh/sshd_config.d/20-no-passwords.conf > /dev/null << 'EOF'
Match Group admins
    PasswordAuthentication no
    KbdInteractiveAuthentication no
EOF
sudo sshd -t && sudo systemctl reload ssh

Este segundo Match Block apila sobre el anterior y elimina la contraseña solo para el grupo admins. Los demás usuarios del sistema siguen pudiendo autenticarse con contraseña mientras migran. Es fundamental probar el acceso con la nueva llave desde otra terminal antes de aplicar la regla, porque un error de sintaxis te deja fuera y la única salida es la consola física o IPMI.

Recuperación de cuenta: el punto débil a diseñar

El riesgo principal de los passkeys es perder el autenticador. Una passkey sincronizada en iCloud se restaura al comprar un dispositivo nuevo con la misma Apple ID, pero si el usuario solo tenía una llave física y se le pierde, queda fuera. El patrón seguro es registrar dos llaves físicas por usuario, una de uso diario y otra guardada en lugar seguro (caja fuerte, depósito bancario).

Para servidores, documenta siempre el procedimiento de recuperación en /etc/ssh/sshd_config con un comentario # recovery cerca del Match Block, y guarda una llave de emergencia sellada en un sobre firmado dentro del datacenter. Esto no es paranoia: es la diferencia entre perder 5 minutos y perder el acceso al servidor indefinidamente.

Qué cambia para tu amenaza de phishing

El ataque clásico de phishing clona la pantalla de login y captura la contraseña. Con passkeys, la firma criptográfica está vinculada al origen del challenge (RP ID), así que un sitio falso no puede reutilizarla. Adicionalmente, verify-required obliga al usuario a tocar físicamente el autenticador, lo que rompe el flujo automático de los bots.

El dato que importa: según el reporte de FIDO Alliance de 2024, Microsoft, Google y Apple vieron reducciones del 90% al 99% en cuentas comprometidas tras desplegar passkeys en sus empleados. No es una mejora incremental, es un cambio de categoría. Para un equipo Linux pequeño con 5 a 20 administradores, replicar ese resultado es cuestión de horas, no de meses.

Checklist de despliegue

1. Verificar ssh -V ≥ 8.2 en todos los servidores objetivo.
2. Comprar dos llaves FIDO2 por administrador (YubiKey 5 NFC o Token2 T2F2).
3. Generar ed25519-sk -O resident -O verify-required para cada admin.
4. Añadir la clave pública a ~/.ssh/authorized_keys y probar login.
5. Configurar Match Block con PasswordAuthentication no solo para Group admins.
6. Para aplicaciones web: integrar @simplewebauthn/server ≥ 13.0 y exigir userVerification: 'required'.
7. Documentar procedimiento de recuperación con la segunda llave sellada.
8. Rotar las claves anualmente o ante sospecha de compromiso.

La migración completa de un equipo pequeño toma una tarde. La parte difícil no es técnica, es logística: coordinar que cada admin compre y configure dos llaves, y dejar la segunda en un lugar seguro antes de deshabilitar la contraseña.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux