Skip to content
La CA SSH de step-ca firma una clave de host y una clave de usuario; el cliente confía en la CA de host y el servidor confía en la CA de usuario, así que ninguno guarda una lista de claves

Inicios de sesión SSH firmados por step-ca: se acabó authorized_keys

step-ca 0.30.2 como autoridad de certificación SSH, probado con OpenSSH 10.0. Por qué los certificados ganan a authorized_keys y a confiar en el primer uso, activar la CA SSH cuando se configura step-ca por primera vez, firmar una clave de host (y el orden de argumentos que la hace tropezar), las dos líneas de sshd_config y la única línea @cert-authority de known_hosts, un certificado de usuario de 16 horas, cuatro pruebas de inicio de sesión incluidos un usuario equivocado y un host no fiable, renovar un certificado de host con sshpop, y dónde se queda corto.

9 de octubre de 2026 · 8 min · 1665 palabras · Damien Dye
step-ca en un contenedor emitiendo certificados desde su intermedio, con una CRL que marca como revocado un móvil perdido

Tu propia autoridad de certificación: step-ca en un contenedor

step-ca 0.30.2 de Smallstep en un contenedor Podman o Docker como autoridad de certificación para todo lo de dentro de casa, todo probado. Por qué una CA privada gana a los certificados autofirmados y a los públicos para nombres internos, arrancarla con ACME y SSH activados, las dos contraseñas que genera la imagen y adónde va cada una, confiar en la raíz en cada dispositivo, HTTPS interno para Caddy o cualquier otra cosa que hable ACME, y step ca renew para los servicios que no. Los certificados de cliente y SSH tienen cada uno su propia entrada.

9 de octubre de 2026 · 8 min · 1852 palabras · Damien Dye