Différences

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

--- reseau:debian:clesshcertificat [2025/07/02 12:22] – [Mise en place du certificat serveur au niveau du client] admin
+++ reseau:debian:clesshcertificat [2025/07/02 12:47] (Version actuelle) – [Révocation globale de clés] admin
@@ Ligne 73: / Ligne 73: @@
 <WRAP center round info>
   * Une passphrase permet de protéger la clé privée.
-Par défaut les clé sont enregistrées dans le dossier **.ssh** :
-  * la **clé privée** s'appelle selon le type **id\_rsa**, **id\_dsa**, **id\_ecdsa** (c'est le cas pour la commande utilisée), **id\_ed25519** ;
-  * la **clé publique** s'appelle selon le type **id\_rsa.pub**, **id\_dsa.pub**, **id\_ecdsa.pub** (c'est le cas pour la commande utilisée), **id\_ed25519.pub**.
-<WRAP center round important>
-Une 2e sécurité est nécessaire pour la clé privée : il est nécessaire de **changer les droits d'accès** pour que seul le compte puisse l'utiliser  :
-<code>
-chmod 600 .ssh/id_rsa
-</code>
-</WRAP>
 </WRAP>
 ===== Format d’une clé publique ssh =====
@@ Ligne 177: / Ligne 168: @@
 Pour indiquer qu'un serveur particulier, présentant un certificat sign par la CA OpenSSH n'est plus de confiance, il suffit d'ajouter dans le fichier **known_hosts** une ligne avec le marqueur **@revoked** associé à la clé publique du serveur.
 </WRAP>
@@ Ligne 263: / Ligne 252: @@
 </code>
   * transférez le certificat sur le poste du client dans son dossier **.ssh**
+Le paramètre -L permet d'afficher le contenu du certificat :
+<code>
+ssh-keygen -L -f /home/charles/id_ecdsa-cert.pub
+/home/charles/id_ecdsa-cert.pub:
+        Type: ecdsa-sha2-nistp256-cert-v01@openssh.com user certificate
+        Public key: ECDSA-CERT SHA256:vq5uCGtqvFGK2CiBX07gtXvfZuGklvnrQ2IBqEoiuzA
+        Signing CA: ECDSA SHA256:t225t0te+LcQXCo1og6TYAnD2PIQ/vnMo/nWL64bIaY (using ecdsa-sha2-nistp256)
+        Key ID: "CHARLES-CERT"
+        Serial: 1
+        Valid: forever
+        Principals:
+                charles
+        Critical Options: (none)
+        Extensions:
+                permit-X11-forwarding
+                permit-agent-forwarding
+                permit-port-forwarding
+                permit-pty
+                permit-user-rc
+</code>
+Commentaires :
+  * le champ **Pricipals** indique le nom d'utilisateur dont qui sera présenté au serveur
+  * l'identifiant **Key ID** est CHARLES-CERT
+  * l'empreinte de la clé publique **Public key** est différente de celle qui a signée le certificat **Signing CA**
 ===== Validation d'un certificat de client SSH =====
@@ Ligne 293: / Ligne 308: @@
+<WRAP center round info>
+L'utilisateur peut maintenant se connecter en SSH au serveur sans avoir au préalable fait renseigner sa clé publique dans le fichier **authorized_keys** du serveur
+</WRAP>
+==== 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 =====