Podman

L'AC SSH de step-ca signe une clé d'hôte et une clé utilisateur ; le client fait confiance à l'AC d'hôte et le serveur à l'AC utilisateur, donc aucun ne tient de liste de clés

Des connexions SSH signées par step-ca : fini authorized_keys

Utiliser step-ca 0.30.2 comme autorité de certification SSH, testé avec OpenSSH 10.0. Pourquoi les certificats battent authorized_keys et la confiance au premier contact, activer l’AC SSH à la première mise en place de step-ca, signer une clé d’hôte (et l’ordre des arguments qui fait trébucher), les deux lignes de sshd_config et l’unique ligne @cert-authority dans known_hosts, un certificat utilisateur de 16 heures, quatre tests de connexion dont un mauvais utilisateur et un hôte non approuvé, le renouvellement d’un certificat d’hôte avec sshpop, et là où ça coince.

step-ca dans un conteneur émettant des certificats depuis son intermédiaire, avec une CRL marquant un téléphone perdu comme révoqué

Votre propre autorité de certification : step-ca dans un conteneur

Faire tourner step-ca 0.30.2 de Smallstep dans un conteneur Podman ou Docker comme autorité de certification de tout ce qui se trouve dans la maison, le tout testé. Pourquoi une AC privée bat les certificats auto-signés et les certificats publics pour les noms internes, le démarrage avec ACME et SSH activés, les deux mots de passe que l’image génère et où va chacun, la confiance dans la racine sur chaque appareil, le HTTPS interne pour Caddy ou tout ce qui parle ACME, et step ca renew pour les services qui ne le parlent pas. Les certificats clients et SSH ont chacun leur propre article.