Skip to content
De SSH-CA van step-ca ondertekent een hostsleutel en een gebruikerssleutel; de client vertrouwt de host-CA en de server vertrouwt de gebruikers-CA, dus geen van beide houdt een lijst met sleutels bij

SSH-aanmeldingen ondertekend door step-ca: geen authorized_keys meer

step-ca 0.30.2 gebruiken als SSH-certificaatautoriteit, getest met OpenSSH 10.0. Waarom certificaten beter zijn dan authorized_keys en vertrouwen bij eerste gebruik, de SSH-CA aanzetten als step-ca voor het eerst wordt ingericht, een hostsleutel ondertekenen (en de volgorde van argumenten die daarbij struikelt), de twee regels in sshd_config en de ene @cert-authority-regel in known_hosts, een gebruikerscertificaat van 16 uur, vier aanmeldtests waaronder een verkeerde gebruiker en een niet vertrouwde host, een hostcertificaat vernieuwen met sshpop, en waar het tekortschiet.

9 oktober 2026 Â· 7 min Â· 1501 woorden Â· Damien Dye
step-ca in een container die certificaten uitgeeft vanaf zijn intermediate, met een CRL die een kwijtgeraakte telefoon als ingetrokken markeert

Je eigen certificaatautoriteit: step-ca in een container

Smallsteps step-ca 0.30.2 in een Podman- of Docker-container draaien als certificaatautoriteit voor alles in huis, en alles getest. Waarom een eigen CA beter is dan zelfondertekende certificaten en publieke certificaten voor interne namen, hem starten met ACME en SSH aangezet, de twee wachtwoorden die het image genereert en waar elk heen gaat, de root vertrouwen op elk apparaat, interne HTTPS voor Caddy of al het andere dat ACME spreekt, en step ca renew voor diensten die dat niet doen. Clientcertificaten en SSH hebben elk een eigen bericht.

9 oktober 2026 Â· 8 min Â· 1724 woorden Â· Damien Dye