Une ancienne clé d’administration se trouve encore dans le dossier du projet. Elle fonctionne sur plusieurs serveurs, mais personne ne sait exactement qui en possède une copie. Le passage des mots de passe aux clés SSH a modifié l’authentification sans clarifier les responsabilités.
Une gestion SSH efficace relie identités individuelles, droits adaptés sur les cibles et révocation fiable. Selon l’environnement, des clés publiques bien entretenues et un inventaire précis peuvent suffire. Les environnements plus grands ou changeant souvent peuvent bénéficier de certificats SSH de courte durée. Les deux approches nécessitent une exploitation maîtrisable.
Quatre éléments à ne pas confondre
La clé privée de l’utilisateur permet de prouver son identité. Elle est conservée de manière protégée et ne se distribue pas par messagerie, courriel ou dossier de projet non protégé. La clé publique correspondante peut être enregistrée sur les systèmes prévus pour autoriser l’accès. Son empreinte facilite son identification sans ambiguïté dans l’inventaire.
La clé d’hôte identifie quant à elle le serveur contacté. La vérification de l’hôte empêche une connexion d’aboutir discrètement au mauvais interlocuteur. Un certificat SSH ajoute à une clé publique une déclaration signée, par exemple sur l’identité et la validité. Les certificats OpenSSH ont leur propre format et ne sont pas des certificats TLS/X.509 ordinaires.
Séparer les connexions personnelles des tâches automatisées
Les activités d’administration sont attribuées à des personnes et à leurs tâches autorisées. Une clé root partagée et durable complique inutilement les départs, la rotation et la traçabilité. Des connexions individuelles avec des droits d’administration encadrés offrent une meilleure base.
Une tâche de sauvegarde ou de déploiement nécessite sa propre identité technique avec une responsabilité documentée. Lorsque c’est possible, son accès est limité à la fonction prévue, par exemple par une commande imposée et des règles de transfert adaptées. La clé privée d’un salarié ne doit pas devenir silencieusement une condition permanente d’une tâche automatisée.
De l’inventaire des clés aux certificats de courte durée
Pour un petit nombre de systèmes, une distribution contrôlée des clés publiques peut suffire. L’inventaire consigne personne ou service, empreinte, systèmes cibles, périmètre et date de vérification ou de remplacement prévue. L’essentiel est de maintenir les autorisations de manière fiable sur toutes les cibles concernées.
Une autorité de certification SSH peut à la place signer des clés publiques pour une durée limitée et des identités définies. Les serveurs font confiance à la CA désignée et vérifient leurs autres règles. La clé privée de connexion n’a pas à être transmise à la CA. Les clés de la CA et ses règles d’émission sont particulièrement protégées.
Une courte validité réduit la durée d’utilisation d’un justificatif émis. Elle ne met pas fin à une session existante et ne remplace pas la révocation. Après un départ, l’émission de nouveaux certificats doit aussi être empêchée. Une plateforme centrale de secrets est un mode d’exploitation possible ; elle doit réellement prendre en charge le processus SSH prévu.
| Mode de gestion | Usage adapté | Exigences d’exploitation |
|---|---|---|
| Entretenir les clés publiques | Un parc cible limité et bien inventorié. | Distribution, suppression des anciens droits et remplacement des responsables absents. |
| Émettre des certificats SSH | Validité limitée et identités définies. | Protection de la CA, règles d’émission, confiance des serveurs et révocation. |
| Identités techniques | Automatisation avec une tâche clairement définie. | Droits cibles limités, responsabilité et procédure de rotation. |
| Agent ou clé matérielle | Modes adaptés de connexion personnelle. | Limites de transfert, vérification des versions et récupération. |
Utiliser les agents et clés matérielles de façon réfléchie
Un agent SSH permet l’authentification avec les clés chargées sans copier le fichier de clé privée sur chaque serveur cible. Le transfert de l’agent donne toutefois à un système distant accès à ses capacités de signature. OpenSSH avertit explicitement qu’un attaquant disposant d’un accès suffisant à ce système peut utiliser les identités chargées pour s’authentifier sans extraire les clés.
Le transfert d’agent est donc prévu uniquement pour le chemin nécessaire. Les restrictions temporelles ou de destination prises en charge peuvent ajouter des limites. Les clés de sécurité matérielles sont une autre option pour les accès interactifs adaptés. Client, serveur, type de clé et exigences de contact ou de PIN doivent être compatibles ; une tâche sans surveillance n’a pas les mêmes besoins qu’une connexion personnelle.
La rotation et la révocation doivent atteindre la cible
Remplacer une clé sur le portable ne supprime pas l’ancien accès sur le serveur. Avec des clés publiques enregistrées, les droits doivent être actualisés sur toutes les cibles concernées. Les certificats peuvent aussi utiliser des mécanismes tels que les listes de révocation OpenSSH. Une révocation ne prend effet que si les serveurs prévus l’appliquent correctement.
Le processus couvre également la perte d’un appareil, une clé compromise et l’indisponibilité du service de gestion. Un accès de secours indépendant est protégé, documenté et testé de manière contrôlée. La récupération ne doit pas dépendre précisément du chemin d’accès défaillant.
Différencier les environnements Linux et Proxmox
Dans un environnement hétérogène, on recense les versions et les fonctions OpenSSH réellement prises en charge. Un manuel actuel ne garantit pas que chaque installation Linux possède les mêmes options. Les nouvelles règles sont introduites avec un accès de test prévu et un retour arrière vérifié.
Proxmox VE utilise aussi SSH pour ses propres fonctions de cluster, notamment certains accès console, migrations et réplications. Ces relations techniques de confiance sont examinées séparément des accès personnels des administrateurs. Une suppression globale ou l’écrasement de fichiers de clés peut perturber l’exploitation. Les modifications sont donc vérifiées dans la documentation de la version installée.
Ce que comprend une première étape maîtrisable
DAXS recense les accès SSH existants, attribue les responsabilités et planifie une gestion adaptée. Le pilote teste connexion, droits, révocation, journalisation et récupération. Une connexion réussie ne suffit pas comme critère de validation. Les seuls journaux de connexion ne constituent pas automatiquement un enregistrement complet de toutes les commandes exécutées.
Les prestations d’infrastructure ainsi que notre article sur Proxmox en entreprise donnent le contexte d’exploitation. Pour les portails partagés, notre article sur les coffres, les rôles et les départs complète cette approche. Vous pouvez demander un inventaire des accès d’administration.
Questions fréquentes
Puis-je transmettre une clé publique ?
La partie publique est destinée à une distribution adaptée. Son association à la bonne personne et à la bonne cible doit néanmoins être vérifiée. La partie privée reste protégée et ne circule pas comme fichier d’accès partagé.
Un certificat de courte durée suffit-il pour une révocation immédiate ?
Non. Émission, validité restante, contrôle de révocation et sessions existantes doivent être examinés ensemble. Une courte durée ne remplace pas ce processus.
Une autorité de certification centrale est-elle toujours nécessaire ?
Non. Taille, fréquence des changements, automatisation et capacité d’exploitation déterminent la solution adaptée. Une gestion rigoureuse des clés peut convenir à un parc limité.
Sources : OpenSSH : authentification et clés autorisées (lien externe) · OpenSSH : certificats et listes de révocation (lien externe) · OpenSSH : règles de confiance et de révocation côté serveur (lien externe) · OpenSSH : transfert d’agent (lien externe) · OpenSSH : clés d’agent et restrictions (lien externe) · Proxmox VE : guide d’administration, SSH dans le cluster (lien externe)
Présentation conceptuelle ; les fonctions concrètes dépendent des versions installées et de la gestion prévue.
