Conseils pour la gestion des clés SSH


13

Quelle est la meilleure pratique que vous ayez trouvée pour gérer de nombreuses paires de clés SSH?

J'utilise SSH pour me connecter à plusieurs systèmes, à la maison et au travail. J'ai actuellement une collection assez petite et gérable de paires de clés pour les systèmes de travail et domestiques. J'ai un script qui génère une paire de clés nommée afin que je puisse éviter toute confusion.

Mon réseau domestique comprend mon ordinateur portable (ubuntu), deux ordinateurs de bureau (ubuntu / fedora dual boot, fedora / windows dual boot) et un système multimédia (ubuntu). Au travail, j'ai mon ordinateur portable personnel (que j'utilise pour travailler à domicile), mon ordinateur de bureau (fedora), un système de production (RHEL) et un ordinateur portable avec des fenêtres (soupir) et une machine virtuelle (fedora). Tout va bien jusqu'à présent.

(Je n'ai aucun intérêt à placer ma paire de clés personnelle sur mon système de travail ou ma paire de clés de travail sur mes systèmes domestiques. Et nous avons des comptes d'utilisateurs virtuels pour mécaniser les transferts de fichiers avec d'autres systèmes, où la clé privée doit résider sur la machine de production, pour transférer des fichiers entre d'autres systèmes.)

Mais vient maintenant Hadoop, un grand cluster de plus de 100 systèmes, et avec cela plus de complexité, plus d'utilisateurs et plus de paires de clés. Maintenant, je dois gérer les clés.

(Je dois clarifier. Je suis un développeur de logiciels consultant un client qui déploie un cluster Hadoop. Ils doivent gérer les clés. Il y aura beaucoup de gens accédant au cluster, qui devront placer leurs clés publiques sur le système. En tant que résident Savant Linux, ils m'ont demandé de l'aide. J'ai conseillé d'embaucher un administrateur système, mais jusqu'à ce qu'ils le fassent, j'aide)

Lorsque j'ai besoin de publier la clé publique sur un système distant, toutes les pages Web `` comment faire '' suggèrent soit d'écraser (>) (détruire les clés existantes), soit d'ajouter (>>) (ce qui est bien, préserve les clés existantes) . Mais je pense que la préservation de chaque clé publique sur la machine de destination séparément, et leur combinaison serait mieux. Je cherche des conseils.

Quelle est la meilleure pratique que vous ayez trouvée pour gérer un grand nombre de clés?

Je vous remercie!


Edit: Un aspect est de devoir placer des clés sur de nombreux systèmes, et le CRUD concomitant (créer, lire, mettre à jour, supprimer / désactiver) pour des utilisateurs spécifiques, ce qui signifie avoir besoin d'être en mesure d'identifier quelles clés appartiennent à quels utilisateurs.


Parlez-vous de paires de clés utilisateur ou hôte? sshfprésout le problème de la clé hôte en plaçant les signatures de la clé publique dans DNS. Pour les informations d'identification de l'utilisateur, vous souhaiterez peut-être examiner les certificats OpenSSH ou utiliser quelque chose comme Spacewalk ou marionnette pour enregistrer toutes les paires de clés dans un emplacement central et les déployer au besoin. On dirait que vous voulez probablement ce dernier puisque vous devez simplement configurer le nouveau serveur en tant que client, puis déployer la dernière version du fichier.
Bratchley

J'ai un autre ordinateur portable (fedora), sur les disques réseau MyBook Live (exécutant linux), deux ordinateurs de bureau intégrés en attente de disques durs et j'en prévois deux autres pour construire un cluster hadoop domestique (apprentissage). Oui, j'ai besoin de comprendre la gestion des clés.
ChuckCottrill

Réponses:


12

En règle générale, vous ne devez pas avoir plus d'une clé par machine cliente (accent sur "généralement"). Je ne sais pas si je comprends bien votre question, mais si vous dites que vous avez une clé distincte pour chaque système distant, vous vous trompez définitivement.

Ssh utilise la cryptographie à clé publique. La clé que vous installez sur le système distant est la clé publique, il n'y a absolument aucun mal à réutiliser cette clé ailleurs. C'est la clé privée qui doit être protégée et qui reste sur votre système personnel.

C'est également une bonne idée que la clé privée réside sur un seul client, non partagée. Ainsi, si un client est compromis, vous pouvez révoquer uniquement cette clé.


Maintenant, si vous demandez comment obtenir votre clé publique sur des centaines de systèmes, il existe deux façons de procéder.

La manière la plus courante consiste à utiliser des répertoires de départ partagés. Avoir un NFS (ou un autre système de fichiers réseau) monté (ou monté automatiquement) sur tous les systèmes.

L'autre façon est de profiter d'une nouvelle fonctionnalité de ssh. C'est une directive de configuration appelée AuthorizedKeysCommand. Fondamentalement, c'est une commande que sshd exécutera chaque fois qu'il aura besoin de rechercher une clé publique. La commande écrit simplement la clé publique de l'utilisateur interrogé dans STDOUT. Ceci est principalement utilisé lorsque vous n'avez pas de répertoires personnels montés, mais que vous avez toujours un serveur d'authentification central ( FreeIPA en profite).

Bien sûr, vous pouvez faire d'autres choses telles que cron job rsync /homedepuis un serveur central. Mais ce n'est pas une pratique courante.


J'ai 8 machines à la maison et un nombre variable de "serveurs" dans le cloud (mis à l'échelle selon les besoins). Il serait idiot d'avoir 300 clés client lorsque j'évolue jusqu'à 300 instances de serveur. J'ai donc 16 clés publiques (2 utilisateurs pour chacun des 8 hôtes). Pour les machines dures, j'appuie sur les touches tous les 3 mois. Pour les instances cloud, elles sont intégrées à l'image personnalisée.
Skaperen

2

Lorsque j'ai besoin de publier la clé publique sur un système distant, toutes les pages Web `` comment faire '' suggèrent soit d'écraser (>) (détruire les clés existantes), soit d'ajouter (>>) (ce qui est bien, préserve les clés existantes) . Mais je pense que la préservation de chaque clé publique sur la machine de destination séparément, et leur combinaison serait mieux. Je cherche des conseils.

je ne vois aucun avantage à stocker les clés publiques à la fois dans .ssh/authorized_keyset dans un fichier séparé.

si vous regardez les clés réelles stockées dans le fichier * authorized_keys *, vous voyez qu'elles contiennent déjà des méta-informations lisibles par l'homme sur l'origine de la clé. Par exemple, la clé publique pour a user@foogénéralement une entrée comme:

ssh-rsa AAAAB3Nza...LiPk== user@example.net

ce qui rend très facile l'inspection / extraction / suppression de certaines clés (attachées à certains utilisateurs) du fichier * authorized_keys *.

l'ID utilisateur est en fait un champ "commentaire" de forme libre, vous pouvez donc y mettre toutes les informations que vous jugez nécessaires pour identifier la clé donnée.

dans tous les cas, vous ne devez générer des paires de clés que pour les "utilisateurs" qui ont besoin d'accéder à des ressources distantes. il est probable que vous n'ayez pas besoin de vous connecter de chaque hôte hadoop à l'autre hôte hadoop. vous aurez plutôt quelques machines de gestion, qui doivent accéder à tous les hôtes hadoop. vous n'avez besoin que d'une seule paire de clés par machine de gestion et installez chaque clé publique sur tous les hôtes hadoop.


Chaque utilisateur générera ses propres clés, je pense que vous dites que chaque utilisateur doit fournir username @ hostname dans le cadre de l'origine de la clé. Ce qui signifie qu'un script qui impose que nom d'utilisateur @ nom d'hôte soit fourni, n'est-ce pas?
ChuckCottrill du

cela dépend de la façon dont ils créent leurs clés; par exemple ssh-keygen, ajoutera un commentaire sur le formulaire user@host; d'autres générateurs de clés (comme celui fourni avec du mastic) pourraient ne pas faire cela. mais oui, il devrait être trivial de faire un petit script qui s'assure que chaque clé a un champ de commentaire qui identifie une combinaison utilisateur / hôte.
umläute

1

OpenSSH récent permet d'obtenir des clés ssh à partir de LDAP, voir 'AuthorizedKeysCommand' dans la page de manuel sshd_config . Personnellement, je préférerais les certificats OpenSSH, pas les clés, voir http://blog.habets.pp.se/2011/07/OpenSSH-certificates . Vous pouvez gérer les clés avec n'importe quel gestionnaire de configuration comme cfengine, marionnette, chef, sel ...


0

Une autre manière qui est super facile à implémenter et permet un peu plus de flexibilité en termes d'ajout de plusieurs utilisateurs est d'utiliser. https://userify.com/

Il vous permet de définir différents groupes de serveurs et d'avoir des clés pour différents utilisateurs activées ou désactivées pour ces serveurs.

Installation et gestion super simples.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.