Différences

Ci-dessous, les différences entre deux révisions de la page.

--- reseau:debian:clesshcertificat [2025/07/02 12:36] – [Génération de la paire de clés privée /publique de la CA OpenSSH] admin
+++ reseau:debian:clesshcertificat [2025/07/02 12:47] (Version actuelle) – [Révocation globale de clés] admin
@@ Ligne 313: / Ligne 313: @@
+==== Révocation globale de clés====
+Au niveau du serveur SSH, la révocation de clés publiques se fait à l'aide de la directive **RevokedKeys** en précisantle nom du fichier global contenant la liste des clés qui doivent être refusées. Cela fonctionne pour toutes les clés publiques, même s'il n'y a pas de certificat associé à la clé.
+<code>
+TrustedUserCAKeys /etc/ssh/ssh_ca_keys
+RevokedKeys /etc/ssh/ssh_revoked_keys
+</code>
+==== Utilisation du fichier authorized_principals ====
+Sur le serveur SSH, l'accès à un autre compte utilisateur que ceux listés dans les **principals** de son certificat est possible en utilisant la directive **AuthorizedPrincipalsFile** dans le fichier de configuration du serveur SSH **/etc/ssh/sshd\_config** :
+<code>
+AuthorizedPrincipalsFile .ssh/authorized_principals
+</code>
+Dans ce cas-là, le serveur vérifie qu'un nom de la liste des **principals** du certificat qu'on lui propose apparaît bien dans le fichier **.ssh/authorized\_principals** du compte cible.
+Depuis le paragraphe 5.1, le certificat de l'utilisateur
+cb
+contientles valeurs
+cb
+,
+borelly
+et
+root
+. Il suffit donc d'indiquer une de ces 3 valeurs dans le fichier
+authorized_principals
+ducompte auquel on désire accéder.
+Le mode debug du serveur SSH nous indique que ce fichier est maintenant bien analysé en premier lieu quand l'utilisateur
+cb
+tente de se connecter sur le compte de
+root
+avec ce certificat :
+root@pccb ~# echo borelly > /root/.ssh/authorized_principals
+root@pccb ~# /usr/sbin/sshd -d
+...
+Failed publickey
 ===== Mise en place côté client =====