Quelle est la stratégie pragmatique commune pour la gestion des paires de clés?
J'ai un petit nombre de postes de travail différents (ainsi que des appareils clients comme l'iPhone) que j'utilise pour me connecter à de nombreux serveurs à l'aide de SSH.
À l'origine, lorsque j'ai découvert PKI, j'ai créé une seule paire de clés sur mon poste de travail, que j'ai rapidement commencé à utiliser de partout (ce qui signifie que je l'ai copiée sur mon ordinateur portable, etc.) et l'ai utilisée pour me connecter à tous mes comptes de serveur.
Depuis lors, j'ai développé l'opinion que cela revient à utiliser un seul mot de passe partout, et je pourrais avoir besoin de révoquer l'accès de manière sélective, par exemple si l'un de mes postes de travail est compromis.
Fondamentalement, j'essaie de développer une stratégie personnelle pour gérer les paires de clés:
Quelle est la bonne façon de penser les paires de clés en toute sécurité pour une utilisation générale, tout en restant pragmatique pour la convivialité? (c'est-à-dire que je ne pense pas que les paires de clés à usage unique pour chaque point de connexion aient également un sens.)
Est-ce mal qu'une paire de clés représente une identité personnelle à l'échelle mondiale à partir de tous les points d'accès ("moi-partout-id_rsa") comme je l'ai fait par le passé, ou est-ce que je pense actuellement qu'une combinaison client-utilisateur unique devrait toujours être représentée par sa propre clé ("me-on-my-personal-laptop-id_rsa") plus appropriée?
Réutilisez-vous la même clé pour vous connecter à tous les serveurs, ou dans quelles conditions envisagez-vous de frapper une clé distincte?
Je préfère avoir une clé par domaine d'authentification. Ainsi, pour chaque ordinateur de bureau ou serveur au travail (tous assez sécurisés physiquement et sous le contrôle d'un seul groupe d'administrateurs), j'ai une clé privée. J'utilise la même clé privée sur mon nouvel ordinateur personnel que mon ancien ordinateur personnel. J'utilise différentes clés sur les ordinateurs portables et autres appareils mobiles. Cette approche permet une gestion fine des risques: je peux révoquer des clés séparément et limiter les possibilités pour mes comptes d'être impliqués dans une infiltration escaladée en n'autorisant pas certaines clés sur certaines machines (je ne fais pas grand chose, mais c'est une option pour le paranoïaque).
Tant que vous ne faites rien de compliqué, la copie des clés publiques n'est pas si difficile. Vous pouvez conserver une grande liste de clés autorisées et la synchroniser partout; inscrire un appareil signifie ajouter un élément à cette liste et pousser la modification. Ce n'est pas beaucoup plus de travail que d'extraire la clé privée, si vous avez un référentiel de données central en premier lieu.
Notez que si l'avantage le plus évident d'avoir des clés privées distinctes est de pouvoir en révoquer une séparément, elles ont également un avantage de disponibilité: si un administrateur système sur la machine A décide de révoquer la clé de la machine C sur laquelle vous vous trouvez, vous pouvez toujours être en mesure de trouver une machine B qui accepte toujours la clé de C et dont la clé est acceptée par A. Cela semble plutôt ésotérique, mais cela m'est arrivé une fois (après Debian a réalisé qu'ils ne semaient pas leur RNG , j'étais content de ne pas avoir à dépendre uniquement d'une clé sur liste noire) alors que je n'ai pas encore eu à révoquer une clé en cas d'urgence.
Il y a même un avantage théorique à conserver une paire de clés distincte par paire de machines, car cela permet des révocations distinctes. Mais l'avantage est extrêmement faible, et la gestion est beaucoup plus difficile (vous ne pouvez plus diffuser de listes d'autorisation). La simplification de la gestion des clés est un avantage essentiel de la cryptographie à clé publique par rapport aux secrets partagés.
Vous avez déjà vu le point principal: si l'une de vos machines est compromise, la clé privée contenue sur cette machine doit être "révoquée": vous devez configurer tous les serveurs sur lesquels vous vous connectez pour rejeter d'autres tentatives d'authentification à l'aide de cette clé (c'est-à-dire que vous supprimez le clé publique correspondante du .ssh/authorized_keys des serveurs). Il existe une technique d'atténuation, qui consiste à sécuriser la clé privée avec un mot de passe (ou mot de passe). Cela vient avec un prix, à savoir que vous devez taper le mot de passe ( ssh-agent peut être très pratique pour cela); d'autre part, cela peut dissuader temporairement l'attaquant d'obtenir la clé privée (cela dépend du type de compromis, mais s'il s'agit d'un vol d'une machine complète - un scénario plausible avec des appareils mobiles - alors le mot de passe empêchera accès immédiat à la clé privée et vous donner un peu de temps pour reconfigurer les serveurs).
On peut noter que "PKI" signifie "Clé publique Infrastructure" et SSH est rudimentaire à cet égard. Dans une PKI à part entière, certificats serait utilisé, avec délégation et centralisation de la révocation. Avec certificats:
- vous créeriez une paire de clés CA, stockée en toute sécurité quelque part;
- pour chaque machine client, vous obtiendriez une nouvelle paire de clés, la clé publique étant signée par l'autorité de certification;
- les serveurs seraient configurés pour accepter automatiquement n'importe quel clé publique signée par l'autorité de certification (ils connaîtraient la clé publique de l'autorité de certification, mais pas les clés individuelles de l'ordinateur client);
- l'autorité de certification conserverait et publierait régulièrement des informations de révocation, c'est-à-dire la liste des clés publiques qui ne doivent plus être acceptées même si ces clés sont signées par l'autorité de certification (les informations de révocation doivent être transmises aux serveurs, ou tiré sur demande).
La grande chose au sujet des certificats est que vous centralisez les décisions, ce qui, en termes pratiques, signifie que si vous vous connectez à 20 serveurs à partir de vos machines clientes, puis ajoutez une nouvelle machine cliente, vous n'avez pas besoin de pousser manuellement la nouvelle clé publique vers tous les 20 serveurs.
OpenSSH , depuis la version 5.4 (publiée le 8 mars 2010), prend en charge certains certificats; voir la section éponyme dans la page de manuel pour ssh-keygen . Les certificats OpenSSH ont un format beaucoup plus simple que les certificats X.509 "habituels" (utilisés avec SSL). La simplification a aussi un prix: il n'y a pas de support de révocation centralisé. Au lieu de cela, si une clé privée est compromise, vous devez toujours mettre sur liste noire la clé publique correspondante sur tous les serveurs, et la liste noire est, dans OpenSSH, une liste blanche (option AuthorizedPrincipalsFile in sshd_config) qui est normalement sous le contrôle de root. La révocation ne fonctionne donc pas bien et vous devez toujours configurer manuellement les choses sur chaque serveur chaque fois que vous créez ou perdez une clé, l'inconvénient exact que PKI était censé supprimer.
Vous pourriez créer des clés limitées dans le temps, car les certificats OpenSSH peuvent incorporer des clés limitées dans le temps. Dans ce cas, vous donneriez à chaque ordinateur client une clé qui est bonne, disons, pour une semaine. Avec des clés qui meurent après une semaine et une clé publique CA connue des serveurs, vous avez la qualité principale de la CA (pas besoin de pousser quoi que ce soit sur tous les serveurs lorsqu'une nouvelle machine est ajoutée au pool de clients), et si un privé clé est compromise, les dommages sont "limités", en supposant que vous disposiez d'un mot de passe clé qui, vraisemblablement, résisterait à une semaine de fissuration (mais cela ne fonctionnera pas si le compromis est une prise de contrôle hostile avec un enregistreur de frappe). Les clés limitées dans le temps peuvent devenir fastidieuses au fil du temps, et elles supposent que tous les serveurs ont une horloge correctement définie, ce qui n'est pas toujours une donnée (il serait malheureux d'être verrouillé sur un serveur car l'horloge du serveur est extrêmement éteinte et réinitialisée l'horloge nécessite un accès SSH au serveur ...).
Un problème supplémentaire avec SSH est qu'il est facile d'ajouter des clés publiques sur chaque serveur. Cela signifie que si un attaquant compromet une clé privée et accède à un serveur - une fois, il peut ajouter sa propre clé publique au .ssh/authorized_keys sur ce serveur, et aucune révocation ne résoudra cela. La révocation est, par nature, un processus asynchrone. Par conséquent, il ne met pas en œuvre un contrôle des dommages suffisamment strict.
Compte tenu des lacunes de la prise en charge SSH des certificats, il n'existe aucun schéma raisonnable qui évite d'avoir à effectuer une configuration sur tous les serveurs dans certaines situations. Vous avez donc essentiellement les choix suivants, lorsque vous ajoutez un nouvel ordinateur client:
Vous copiez la clé privée d'un autre ordinateur client (c'est ce que vous faites en ce moment). Cela ne nécessite aucune configuration supplémentaire sur les serveurs.
Vous créez une nouvelle paire de clés pour cette machine. Vous devez envoyer la clé publique à tous les serveurs.
En cas de compromis sur une clé, vous devez vous connecter à tous les serveurs pour supprimer la clé publique correspondante de tous les .ssh/authorized_keys. C'est inévitable (pour l'éviter, vous devrez utiliser des certificats, et SSH n'est pas bon en certificats, voir ci-dessus). Ensuite, si vous avez utilisé le choix 1, alors vous devez aussi créer une nouvelle paire de clés et la pousser vers tous les clients = machines qui utilisaient une copie de la clé privée compromise.
Par conséquent, le choix 1 implique moins de travail de configuration que le choix 2 dans le cas normal, mais les choses sont inversées si un compromis clé se produit. Étant donné que les compromis sont normalement des événements rares, cela favoriserait le choix 1 (ce que vous faites déjà). Je vous suggère donc de protéger votre clé privée avec un mot de passe fort et de la copier sur tous vos systèmes clients.
Remarque: dans tout ce qui précède, j'ai supposé que vous vouliez vous connecter à une liste de serveurs avec SSH, et que vous vouliez accéder à l'un des serveurs depuis n'importe laquelle de vos machines clientes. Vous peut-être souhaitez restreindre l'accès, comme accéder à un serveur donné uniquement à partir d'une ou deux machines clientes spécifiques. Cela peut être fait avec plusieurs clés client, mais la complexité de la configuration augmente de façon quadratique.
Fondamentalement, j'essaie de développer une stratégie personnelle pour gérer les paires de clés
Si vous êtes principalement responsable des serveurs en question, je vous suggère fortement de considérer la recherche d'outils de gestion de configuration comme marionnette/chef. Les deux ont des méthodes pour distribuer les clés SSH sur vos machines.
La raison pour laquelle j'ai commencé à utiliser des marionnettes était précisément parce que je voulais un bon moyen de révoquer rapidement une clé sur mes ~ 60 serveurs Linux lorsque le personnel changeait.
Lorsque vous disposez d'un outil de gestion de configuration pour gérer vos clés, il devient beaucoup plus facile d'avoir de nombreuses paires de clés. Au lieu d'avoir à révoquer manuellement une clé sur chaque boîte, ou ajouter une nouvelle clé sur chaque boîte, vous ajoutez simplement la clé publique sur le maître de configuration, et les clients mettront à jour les listes d'autorisation dans l'intervalle d'interrogation que vous définissez pour votre gestion de configuration outil.
Cela signifie que vous accordez une grande confiance à votre hôte de gestion de configuration non compromis. Puisqu'il exécute généralement des tâches avec des privilèges root sur chaque machine sur laquelle vous le configurez, vous devez vous assurer qu'il est bien verrouillé, avec beaucoup d'audits. Si un attaquant devait compromettre le maître de configuration, il pourrait faire quelque chose comme ajouter de nouvelles clés, ajouter de nouveaux comptes, etc.
J'utilise une clé par domaine et par machine. 4 télécommandes accessibles depuis 2 postes de travail => 8 clés privées. Ne copiez jamais une clé privée d'un hôte à un autre. Si un poste de travail est compromis, révoquez toutes ces clés.
Comme créer des clés et configurer SSH pour les utiliser est assez fastidieux, j'ai écrit un outil dédié à la gestion de mes clés SSH pour l'accès Github: github-keygen .