Différences

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

--- reseau:debian:clesshcertificat [2025/07/02 11:59] – [Validation généralisée de certificats] 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 98: / Ligne 89: @@
 **Commentaire facultatif** : information pour identifier la clé : nom d'utilisateur et l'hôte depuis lequel la clé a été générée.
-===== Génération d'un certificat SSH =====
-Les certificats OpenSSH permettent d'ajouter :
-  * des informations sur l'**identité** du propriétaire de la clé publique
-  * et des **contraintes de validité**.
-Pour signer un certificat avec ssh-keygen, deux paramètres au minimum sont nécessaires :
-  * paramètre **-s** pour indiquer la clé privée qui va **signer** : sa propre clé privée ou celle de la CA OpenSSH
-  *  le paramètre **-I** pour indiquer l'**identifiant du certificat** (Key ID).
-Le nom du fichier de certificat est généré en ajoutant **-cert.pub** au nom de la clé publique.
@@ Ligne 188: / 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>
-===== Mise en place du certificat serveur au niveau du client =====
+==== Mise en place du certificat serveur au niveau du client ====
 La configuration du client permet à celui-ci de faire confiance à n'importe quel serveur qui présente un certificat signé par une CA préalablement définie.
@@ Ligne 250: / Ligne 228: @@
 ===== Génération d'un certificat utilisateur signé par la CA OpenSSH =====
+===== Génération du certificat utilisateur =====
+Les certificats OpenSSH permettent d'ajouter :
+  * des informations sur l'**identité** du propriétaire de la clé publique
+  * et des **contraintes de validité**.
+Pour signer un certificat avec ssh-keygen, deux paramètres au minimum sont nécessaires :
+  * paramètre **-s** pour indiquer la clé privée qui va **signer** : sa propre clé privée ou celle de la CA OpenSSH
+  *  le paramètre **-I** pour indiquer l'**identifiant du certificat** (Key ID).
+Il est cependant indispensable de préciser :
+  * une ou plusieurs valeurs de **principals** avec le paramètre -n chaque **principal** est un nom d'utilisateur dotn on peut prendre l'identité
+Le nom du fichier de certificat est généré en ajoutant **-cert.pub** au nom de la clé publique.
+Sur le serveur ayant les clé de la CA OpenSSH, signez la clé publique de l'utilisateur :
+  * transférez la clé publique de l'utilisateur sur le serveur
+  * signez la clé publique avec la clé privée de la CA **/etc/ssh/ssh\_c**.
+<code>
+ssh-keygen -s /etc/ssh/ssh_ca -I CHARLES-CERT \
+-z 1
+-n charles
+ id_rsa.pub
+</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 =====
 Il y a plusieurs méthodes :
   * **méthode globale** qui s'applique à tous les utilisateurs ;
@@ Ligne 272: / Ligne 302: @@
 **IMPORTANT** : le certificat du client ne sera considéré que si sa liste de nom-clés (principal) contient le nom du compte auquel il tente de se connecter.
-SAUF si un fichier spécifique à chaque compte indique la liste des noms-clés acceptés. Directive **AuthorizedPrincipalsFile** dans sshd_config
+SAUF si un fichier spécifique à chaque compte indique la liste des noms-clés acceptés. Directive **AuthorizedPrincipalsFile** dans **sshd\_config**
 </WRAP>
+  * Redémarrez ensuite le service SSH
+<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 =====
 Quand un client accepte pour la première fois la connexion à un serveur, il enregistre dans le fichier **~/.ssh/know\_hosts** une ligne avec la clé publique du serveur.