La CA firma las claves públicas de las personas autorizadas y genera certificados con principals, restricciones, número de serie y una vigencia determinada. Los servidores solo necesitan la clave pública de la CA, un mapeo de principals y, opcionalmente, una lista de revocación.

Advertencia: una configuración incorrecta de sshd puede bloquear todo acceso remoto. Mantén una sesión SSH abierta, una clave de rescate funcional y acceso a la consola del proveedor durante la migración.

Qué se va a construir

La solución tendrá:

• Una CA exclusiva para certificados de usuario.
• Claves privadas generadas y conservadas por cada usuario.
• Certificados de corta duración.
• Un principal funcional, como ops.
• Mapeo entre principals y cuentas Unix.
• Restricciones para forwarding y sesiones.
• Revocación mediante una KRL.
• Un procedimiento de rotación y recuperación.

Los certificados de usuario autentican personas ante servidores. Los certificados de host resuelven el problema inverso: permiten que los clientes autentiquen servidores. Deben utilizar CA diferentes. Certificados en ssh-keygen.

Cómo funciona la cadena de confianza

El flujo es:

1. La persona genera una clave SSH en su estación.
2. Entrega únicamente la clave pública a la CA.
3. La CA comprueba la identidad y autorización solicitada.
4. La CA firma la clave pública con principals y vigencia limitada.
5. El cliente presenta el certificado y demuestra que posee la clave privada.
6. El servidor verifica la firma, el principal, la vigencia y la revocación.

Ni la clave privada de la persona ni la clave privada de la CA deben copiarse a los servidores.

El certificado tampoco crea cuentas Unix, permisos sudo ni políticas de acceso. La cuenta destino debe existir y sus privilegios deben administrarse por separado.

Requisitos previos

Necesitas:

• OpenSSH Client y Server instalados.
• Acceso administrativo a un servidor de ensayo.
• Una consola alternativa o sesión SSH de rescate.
• Sincronización horaria operativa en CA, clientes y servidores.
• Un sistema para registrar solicitudes, seriales y revocaciones.
• Un equipo fuera de los servidores para custodiar la CA.

Comprueba las versiones:

ssh -V
sudo sshd -T >/dev/null

El borrador utilizaba ssh-keygen --version, pero esa opción no es una comprobación portable. ssh -V muestra la versión del cliente y sshd -T valida y vuelca la configuración efectiva del servidor.

Comprueba el reloj:

timedatectl status

Una diferencia horaria puede hacer que un certificado todavía no sea válido o aparezca como expirado.

Paso 1: crear una CA para usuarios

Ejecuta este paso en un equipo protegido, preferiblemente desconectado o respaldado por un HSM.

umask 077
mkdir -p ~/openssh-user-ca
cd ~/openssh-user-ca

Genera la CA:

ssh-keygen \
  -t ed25519 \
  -a 64 \
  -f user_ca \
  -C "OpenSSH User CA - ejemplo.com"

Introduce una passphrase robusta cuando ssh-keygen la solicite. No utilices -N "" para una CA productiva.

Se crearán:

user_ca       # Clave privada: altamente sensible
user_ca.pub   # Clave pública: se distribuye a los servidores

Comprueba la huella:

ssh-keygen -lf user_ca.pub

Registra esa huella por un canal independiente. La clave privada debe tener acceso restringido, backups cifrados y un procedimiento de recuperación documentado.

Paso 2: generar una KRL inicial

RevokedKeys debe apuntar a un archivo legible y válido. Si el archivo falta o no puede leerse, sshd puede rechazar toda autenticación por clave pública.

Crea una especificación vacía:

install -m 600 /dev/null empty-krl.spec

Genera una KRL válida sin revocaciones:

ssh-keygen \
  -k \
  -f revoked_keys.krl \
  -s user_ca.pub \
  empty-krl.spec

Comprueba su formato:

ssh-keygen -Q -l -f revoked_keys.krl

La KRL debe mantenerse junto al registro de seriales y distribuirse a todos los servidores de manera controlada.

Paso 3: preparar el servidor

Los ejemplos utilizan:

• Cuenta Unix: admin.
• Principal del certificado: ops.
• CA pública: /etc/ssh/user_ca.pub.
• Principals: /etc/ssh/auth_principals/admin.
• KRL: /etc/ssh/revoked_keys.krl.

Confirma que la cuenta existe:

getent passwd admin

Instala la clave pública de la CA y la KRL:

sudo install -o root -g root -m 0644 \
  user_ca.pub /etc/ssh/user_ca.pub

sudo install -o root -g root -m 0644 \
  revoked_keys.krl /etc/ssh/revoked_keys.krl

Nunca copies user_ca al servidor.

Crea el directorio para principals:

sudo install -d \
  -o root -g root -m 0755 \
  /etc/ssh/auth_principals

Crea /etc/ssh/auth_principals/admin con este contenido:

ops

Aplica permisos:

sudo chown root:root /etc/ssh/auth_principals/admin
sudo chmod 0644 /etc/ssh/auth_principals/admin

Esto permite que un certificado con el principal ops autentique la cuenta Unix admin.

Paso 4: configurar sshd

Comprueba primero si la configuración principal incluye archivos adicionales:

sudo sshd -T | head
sudo grep -n '^Include' /etc/ssh/sshd_config

Si la distribución admite /etc/ssh/sshd_config.d/, crea un archivo como:

/etc/ssh/sshd_config.d/60-user-ca.conf

Contenido:

PubkeyAuthentication yes
TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
RevokedKeys /etc/ssh/revoked_keys.krl

TrustedUserCAKeys acepta una o varias claves públicas de CA. Cuando se configura AuthorizedPrincipalsFile, al menos uno de los principals del certificado debe aparecer en el archivo correspondiente a la cuenta destino. Referencia de sshd_config.

Durante la migración conserva:

AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

No desactives todavía contraseñas ni elimines las claves de rescate.

Paso 5: validar antes de recargar

Comprueba la sintaxis:

sudo sshd -t

Cuando el comando no imprime nada y devuelve código cero, la sintaxis es válida.

Comprueba la configuración efectiva para una conexión de ejemplo:

sudo sshd -T \
  -C user=admin,host=servidor.ejemplo.com,addr=203.0.113.20 |
grep -E \
  'pubkeyauthentication|trustedusercakeys|authorizedprincipalsfile|revokedkeys'

Esto también ayuda a detectar directivas sobrescritas dentro de bloques Match.

Recarga el servicio correspondiente a tu distribución:

sudo systemctl reload ssh

En distribuciones donde la unidad se llama sshd:

sudo systemctl reload sshd

Una recarga normalmente conserva las sesiones existentes. No cierres la sesión administrativa actual.

Paso 6: generar la clave del usuario

La clave debe generarse en la estación de la persona:

ssh-keygen \
  -t ed25519 \
  -a 64 \
  -f ~/.ssh/ana_ed25519 \
  -C "[email protected]"

La persona conserva:

~/.ssh/ana_ed25519

Solo debe enviar a la CA:

~/.ssh/ana_ed25519.pub

Comprueba la huella de la solicitud:

ssh-keygen -lf ~/.ssh/ana_ed25519.pub

La CA debe verificar esa huella, la identidad de la persona, el principal solicitado, el alcance y la duración antes de firmar.

Paso 7: firmar el certificado

En el equipo de la CA:

ssh-keygen \
  -s user_ca \
  -I "[email protected]:ticket-1234" \
  -n ops \
  -V -5m:+8h \
  -z 1042 \
  -O clear \
  -O permit-pty \
  ana_ed25519.pub

El resultado será:

ana_ed25519-cert.pub

Significado de las opciones:

• -s user_ca: clave privada utilizada para firmar.
• -I: identificador visible en los registros del servidor.
• -n ops: principal autorizado.
• -V -5m:+8h: válido desde cinco minutos antes hasta ocho horas después.
• -z 1042: serial único y no nulo.
• -O clear: elimina las extensiones permitidas por defecto.
• -O permit-pty: vuelve a permitir únicamente la asignación de terminal.

Con esta combinación no se habilitan agent forwarding, port forwarding, X11 forwarding ni ejecución de ~/.ssh/rc.

Si el acceso debe limitarse a una red conocida, puede añadirse:

-O source-address=203.0.113.0/24

Es una opción crítica: úsala únicamente si el origen es estable. NAT, VPN o cambios de dirección pueden impedir el acceso.

Si no se especifica -V, OpenSSH genera certificados con una vigencia extremadamente amplia. Define siempre una ventana explícita. Las opciones y restricciones se describen en el manual oficial de ssh-keygen.

Paso 8: inspeccionar el certificado

Antes de entregarlo:

ssh-keygen -L -f ana_ed25519-cert.pub

Verifica:

• Tipo user certificate.
• Huella de la CA.
• Key ID.
• Serial.
• Ventana de validez.
• Principal ops.
• Critical options.
• Extensions.

Registra como mínimo:

serial | key ID | huella | principal | emisión | expiración | solicitud

La persona puede recibir el certificado por un canal autenticado. El certificado es público, pero su integridad y procedencia deben verificarse.

Paso 9: configurar el cliente

Guarda el certificado junto a la clave privada:

~/.ssh/ana_ed25519
~/.ssh/ana_ed25519-cert.pub

OpenSSH intenta descubrir automáticamente el archivo -cert.pub asociado a un IdentityFile. También puede declararse explícitamente en ~/.ssh/config:

Host servidor-ejemplo
    HostName servidor.ejemplo.com
    User admin
    IdentityFile ~/.ssh/ana_ed25519
    CertificateFile ~/.ssh/ana_ed25519-cert.pub
    IdentitiesOnly yes

IdentitiesOnly yes evita que el cliente ofrezca otras claves cargadas en el agente. Configuración oficial del cliente.

Aplica permisos:

chmod 600 ~/.ssh/ana_ed25519
chmod 644 ~/.ssh/ana_ed25519-cert.pub

Paso 10: probar sin cerrar la sesión de rescate

Abre una segunda terminal:

ssh -vv servidor-ejemplo

En el servidor, revisa los logs:

sudo journalctl -u ssh --since "10 minutes ago"

O, según la distribución:

sudo journalctl -u sshd --since "10 minutes ago"

Comprueba:

• Que se utilizó el certificado.
• Que la CA coincide.
• Que aparece el Key ID esperado.
• Que el principal fue aceptado.
• Que no se utilizó una clave antigua o contraseña.

Prueba también un certificado:

• Expirado.
• Con otro principal.
• Firmado por una CA no confiable.
• Revocado mediante KRL.

Paso 11: endurecer la autenticación

Solo después de comprobar varios usuarios, servidores y mecanismos de recuperación, evalúa:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Mantén temporalmente una clave de emergencia en authorized_keys, protegida por procedimiento, monitorización y acceso restringido.

No configures AuthorizedKeysFile none hasta completar la migración y comprobar el acceso de rescate desde la consola.

Antes de cada recarga:

sudo sshd -t

Revocar un certificado

Supón que debe revocarse el serial 1042. Crea revoked.spec:

serial: 1042

Actualiza la KRL:

ssh-keygen \
  -k \
  -u \
  -f revoked_keys.krl \
  -s user_ca.pub \
  revoked.spec

-u agrega la nueva revocación a la KRL existente.

Comprueba el certificado:

ssh-keygen \
  -Q \
  -f revoked_keys.krl \
  ana_ed25519-cert.pub

Para un certificado revocado, ssh-keygen informa REVOKED y devuelve un código distinto de cero. Un código cero significa que la clave consultada no está revocada. Listas KRL en OpenSSH.

Distribuye la KRL de forma atómica:

sudo install \
  -o root -g root -m 0644 \
  revoked_keys.krl \
  /etc/ssh/revoked_keys.krl.new

sudo mv \
  /etc/ssh/revoked_keys.krl.new \
  /etc/ssh/revoked_keys.krl

OpenSSH recomienda reemplazar este archivo de forma atómica y no modificarlo directamente mientras el servidor lo consulta.

La KRL bloquea nuevas autenticaciones. No termina sesiones SSH que ya estaban abiertas. Si el incidente lo exige, identifica y finaliza esas sesiones mediante el procedimiento de respuesta de la organización.

Expiración frente a revocación

Ambos mecanismos son complementarios:

• Vigencia corta: limita cuánto puede utilizarse un certificado olvidado o copiado.
• KRL: bloquea inmediatamente nuevas autenticaciones antes de que expire.
• Finalización de sesiones: responde a conexiones ya establecidas.
• Rotación de clave personal: necesaria cuando se compromete la clave privada del usuario.

Una CA no elimina la necesidad de un proceso de baja de personal, inventario de activos y respuesta a incidentes.

Rotar la CA

TrustedUserCAKeys puede contener varias claves públicas. Esto permite una rotación con solapamiento:

1. Generar una CA nueva.
2. Distribuir su clave pública junto a la anterior.
3. Emitir certificados con la CA nueva.
4. Comprobar clientes y servidores.
5. Retirar la confianza en la CA anterior.
6. Conservar registros y backups según la política definida.

Si la clave privada de la CA se compromete, la rotación normal no es suficiente: retira inmediatamente su clave pública de todos los servidores, activa el acceso de emergencia y emite nuevos certificados desde una CA segura.

CA de usuarios frente a CA de hosts

No reutilices la misma clave para ambos propósitos.

• La CA de usuarios firma claves de personas y es confiada mediante TrustedUserCAKeys.
• La CA de hosts firma claves de servidores con ssh-keygen -h.
• Los servidores configuran sus certificados mediante HostCertificate.
• Los clientes confían en la CA de hosts con una entrada @cert-authority en known_hosts.

Separar ambas CA reduce el impacto de una filtración y evita confundir autenticación de personas con autenticación de servidores.

Rollback seguro

Durante la implementación:

• Conserva una sesión administrativa abierta.
• Mantén authorized_keys y la clave de rescate.
• Guarda una copia de la configuración anterior.
• No reinicies sshd si una recarga es suficiente.
• Valida siempre con sshd -t.

Si el acceso por certificado falla:

1. Restaura la configuración anterior desde la consola o sesión abierta.
2. Ejecuta sudo sshd -t.
3. Recarga el servicio.
4. Comprueba el acceso mediante la clave de rescate.
5. Revisa CA, principal, vigencia, permisos y KRL antes de reintentar.

Problemas frecuentes

Certificate invalid: not yet valid o expired

Comprueba el reloj y la ventana del certificado:

date -u
ssh-keygen -L -f ~/.ssh/ana_ed25519-cert.pub

El principal no está autorizado

Compara:

ssh-keygen -L -f ~/.ssh/ana_ed25519-cert.pub
sudo cat /etc/ssh/auth_principals/admin

Al menos un principal debe coincidir.

El cliente ofrece la clave, pero no el certificado

Comprueba:

ssh -G servidor-ejemplo |
grep -E 'identityfile|certificatefile|identitiesonly'

Revisa el nombre ana_ed25519-cert.pub o configura CertificateFile.

Toda autenticación por clave pública dejó de funcionar

Revisa inmediatamente:

sudo sshd -t
sudo ls -l /etc/ssh/revoked_keys.krl

Un archivo KRL ausente, ilegible o inválido puede provocar el rechazo general de claves públicas.

La configuración parece ignorarse

Comprueba la configuración efectiva y los bloques Match:

sudo sshd -T \
  -C user=admin,host=servidor.ejemplo.com,addr=203.0.113.20

Buenas prácticas para producción

• Mantén la CA privada fuera de los servidores.
• Utiliza CA diferentes para usuarios y hosts.
• Protege la CA mediante passphrase, HSM o token criptográfico.
• Emite certificados de corta duración.
• Usa seriales únicos y Key IDs trazables.
• Parte de -O clear y habilita solo lo necesario.
• Limita principals por función y cuenta destino.
• Distribuye CA públicas y KRL mediante gestión de configuración.
• Reemplaza las KRL de forma atómica.
• Conserva un acceso de emergencia auditado.
• Monitoriza Key ID, principal, serial, origen y cuenta destino.
• Ensaya revocación, rotación y recuperación periódicamente.
  
  

Conclusión

Una CA OpenSSH centraliza la confianza y permite emitir accesos temporales, trazables y restringidos sin distribuir cada clave pública a todos los servidores.

Su seguridad depende del proceso completo: proteger la CA, verificar solicitudes, limitar vigencia y capacidades, mapear principals correctamente, mantener una KRL actualizada y conservar un acceso de emergencia probado.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting