Skip to content
step-ca's SSH CA signs a host key and a user key; the client trusts the host CA and the server trusts the user CA, so neither keeps a list of keys

SSH Logins Signed By step-ca: No More authorized_keys

Using step-ca 0.30.2 as an SSH certificate authority, tested with OpenSSH 10.0. Why certificates beat authorized_keys and trust-on-first-use, switching the SSH CA on when step-ca is first set up, signing a host key (and the argument order that trips it), the two sshd_config lines and the single @cert-authority line in known_hosts, a 16-hour user certificate, four login tests including a wrong user and an untrusted host, renewing a host certificate with sshpop, and where it falls down.

9th October 2026 Â· 7 min Â· 1496 words Â· Damien Dye
step-ca in a container issuing certificates from its intermediate, with a CRL marking a lost phone as revoked

Your Own Certificate Authority: step-ca In A Container

Running Smallstep’s step-ca 0.30.2 in a Podman or Docker container as the certificate authority for everything inside the house, all of it tested. Why a private CA beats self-signed certificates and public ones for internal names, starting it with ACME and SSH switched on, the two passwords the image generates and where each one goes, trusting the root on every device, internal HTTPS for Caddy or anything else that speaks ACME, and step ca renew for services that do not. Client certificates and SSH each have their own post.

9th October 2026 Â· 8 min Â· 1690 words Â· Damien Dye