Système de gestion centralisé pour les clés SSH?

27

Nous cherchons à passer à la gestion par clé des connexions SSH et nous nous demandons s'il existe des systèmes de gestion des clés qui nous permettraient de gérer de manière centralisée les clés d'accès dans le monde entier.

Le système devrait idéalement permettre de délivrer des clés par client et de les révoquer si nécessaire, en mettant à jour les clés de la machine serveur à la volée.

Quelqu'un connaît-il un tel système, qu'il soit commercial ou open source?

REMARQUE: pour clarifier, nous avons besoin de la gestion des clés pour une assez grande quantité de serveurs cloud (de type EC2) et une petite quantité d'utilisateurs de services. Je suppose que le patch LDAP + suggère ci-dessous pourrait être la voie à suivre.

ssh cloud keys

— SyRenity
source

7

Est-ce seulement moi qui pense que "les clés privées et le cloud" sont comme "boire et conduire". Les deux se moquent séparément mais ne vont jamais ensemble.

— mailq

1

"Cloud" est probablement le mauvais mot - il semble que ce qu'ils veulent, c'est une authentification centralisée, avec une cohérence mondiale.

— voretaq7

Salut. Exactement - c'est ce que nous recherchons.

— SyRenity

Je me bats avec ce problème avec certains de mes environnements hybrides clients. Il y a aussi la question de savoir où conserver l'OPenLDAP ou l'instance centrale dans un déploiement cloud? J'ai utilisé Webmin de toutes choses comme un outil de gestion des clés et un livre de recettes de chef pour synchroniser les clés vers les nœuds.

— Tom H

Userify couvre ce que vous recherchez (voir serverfault.com/questions/647797/… )

— Jamieson Becker

8

Il existe de nombreuses façons de procéder. Le stockage de clés LDAP a été mentionné plusieurs fois, et je l'ai fait et cela fonctionne, pour autant qu'il le fasse. LDAP a ses propres curiosités de gestion, cependant, qui nécessitent un certain apprentissage.

Je suis un grand fan de serveurs simples et robustes qui ont des dépendances réseau externes minimales pour des choses simples comme l'authentification des administrateurs, donc je penche vers une stratégie de distribution de clés SSH beaucoup plus robuste - j'ai le système de gestion de configuration qui s'en occupe. La clé publique de chacun est conservée dans le système de gestion de la configuration, et partout où la personne doit pouvoir se connecter, sa clé est ajoutée. Le système de configuration sait également supprimer les clés qui ne sont pas spécifiées, donc quand quelqu'un quitte ou que sa clé change, il suffit de supprimer la configuration de clé et lors de la prochaine exécution du système de configuration, la clé est supprimée.

— womble
source

Cette approche est certainement bonne, et comme le souligne Womble, elle a un avantage dans la mesure où les serveurs restent opérationnels (et accessibles) en cas de panne de LDAP - Chaque système soutenu par LDAP devrait (oserais-je dire doit ) avoir à au moins un utilisateur dont les touches sont poussées comme décrit par Womble. L'inconvénient est que vous devez exécuter une configuration pour annuler l'autorisation des utilisateurs. Pas de problème pour un "compte d'urgence" avec seulement quelques utilisateurs autorisés. Plus gros problème pour un grand nombre de comptes :)

— voretaq7

1

Vous devez vraiment avoir un moyen de déclencher des exécutions de configuration de masse de toute façon, donc cela ne devrait pas être un problème de le faire pour un changement de compte.

— womble

Je suis d'accord, malheureusement, les besoins / mentalités des entreprises ne le font pas: la paranoïa à de nombreux endroits (le mien inclus) dicte que les poussées de configuration se produisent pendant les heures creuses, mais de nouveaux employés /

— départs

1

Vous êtes donc heureux de laisser des trucs cassés pour un jour ouvrable simplement parce que vous ne pouvez pas exécuter une poussée de configuration pendant la journée? Ce n'est pas parce que c'est courant que ce n'est pas stupide.

— womble

2

Salut. Ainsi, une bonne idée serait d'utiliser Puppet pour cela, par exemple?

— SyRenity

23

Les paires de clés doivent être générées par l'utilisateur.

L'utilisateur conserve la moitié privée - vous ne devriez jamais la voir. Si vous avez la clé privée de quelqu'un sous une forme où vous pouvez la lire / l'utiliser, vous faîtes mal la sécurité.

La moitié publique vous est donnée (par le mécanisme que vous souhaitez: formulaire Web, e-mail, donnez-le-moi sur un CD), à centraliser comme vous le souhaitez. Certains endroits stockent les clés publiques dans LDAP. D'autres poussent des authorized_keysfichiers à l'aide de leur système de déploiement.

Dans mon environnement, les utilisateurs qui ont besoin d'un accès shell me donnent leurs clés publiques. Ces clés sont ajoutées à notre système LDAP et sshdconsultent la ou les clés publiques répertoriées pour chaque utilisateur pour les authentifier, via le correctif de clé publique LDAP .
Lorsque quelqu'un a besoin d'ajouter une clé supplémentaire ou de révoquer une clé existante, il en informe un administrateur et nous nous en occupons. Finalement, à mesure que nous évoluerons, j'implémenterai un système qui permet aux gens de faire pivoter leurs propres clés publiques.

Chacun de nos sites possède une paire de serveurs LDAP, synchronisés avec notre maître avec la réplication LDAP, qui maintient les données cohérentes (et accessibles) à chaque emplacement.

Tout ce que j'ai décrit peut être fait avec un logiciel open source. Il existe également des produits commerciaux qui font la même chose.
Vous devez rechercher les options disponibles de manière plus approfondie et décider laquelle convient le mieux à votre environnement. Si vous avez d'autres questions (plus spécifiques), nous pouvons probablement être plus utiles.

— voretaq7
source

Donc, fondamentalement, vous proposez d'utiliser l'infrastructure LDAP, avec OpenSSH patché qui fonctionnera avec LDAP? Dans quelle mesure cela évolue-t-il dans la production? Peut-il prendre en charge une grande quantité de machines? Nous ne devons prendre en charge qu'une petite quantité d'utilisateurs de services.

— SyRenity

1

@SyRenity: LDAP prend en charge la réplication et le clustering, donc il évolue très bien

— Hubert Kario

@SyRenity Théoriquement, vous pouvez prendre en charge un nombre illimité de machines à un nombre illimité d'emplacements (pensez "Déploiement d'Active Directory vraiment grand" - AD est essentiellement LDAP avec quelques accessoires à la mode). Pour les utilisateurs de services ma suggestion est de les standardiser dans votre environnement et pousser standardisés /etc/passwdet des /etc/groupfichiers (permet aux machines de fonctionner normalement et les services associés pour démarrer / exécuter même si LDAP est non disponible)

— voretaq7

@ voretaq7 Cela signifie que les utilisateurs du service seront gérés séparément de LDAP, via la gestion de la configuration?

— SyRenity

@SyRenity yes - et plus important encore disponible pour les services qui les utilisent si LDAP est en panne . Planifiez les échecs ou vous subirez des catastrophes.

— voretaq7

9

Les paires de clés ne doivent pas être générées ailleurs que sur l'ordinateur de chaque utilisateur. Les clés privées sont nommées comme telles pour une raison.

Cela dit, je pouvais voir un cas d'utilisation pour une sorte de référentiel centralisé des clés publiques des utilisateurs. Une option serait de stocker les clés publiques dans OpenLDAP - les versions récentes d'OpenSSH peuvent lire les clés dans LDAP.

— EEAA
source

2

Le contenu de la clé publique LDAP est-il maintenant dans OpenSSH? Je ne connais que le patch LPK (pour lequel je peux me porter garant - il fonctionne très bien). +1 également pour garder les clés privées privées.

— voretaq7

@ voretaq7 Je suppose que j'ai entendu dire qu'il allait fusionner avec la ligne principale, mais je ne l'ai pas encore vérifié moi-même. Nous faisons des répertoires personnels partagés via NFS, donc cela prend soin de notre distribution de clés pour nous.

— EEAA

+1 je ne le savais pas. cela me sauverait un tas de problèmes. c'est maintenant sur ma liste de choses à examiner.

— Tom H

1

Je sais que c'est une question un peu plus ancienne, mais Google la renvoie assez haut lors de la recherche de ce genre de chose.

Pour ceux d'entre nous qui recherchent une solution en dehors de LDAP, je viens de trouver le projet "SKM": https://sites.google.com/site/jeromeboismartel/code-s-corner/ssh-key-management-with-skimp

— fukawi2
source

1

Il existe de nombreuses excellentes solutions commerciales et open source, telles que Userify [1] (où je travaille), Universal Key Manager [2], SSH Key Box [3], etc. Cela dépend de vos besoins et si vous êtes chercher quelque chose qui centralise la gestion tout en décentralisant les opérations (afin que vos serveurs ne dépendent pas d'une autorité centrale pour se connecter ... dans ce cas, vous ne pourrez peut-être pas vous connecter à aucun de vos serveurs, si, par exemple, votre Le serveur LDAP est en panne!)

Voir aussi cette discussion Slant:

https://www.slant.co/topics/8010/~managers-for-ssh-keys

— Jamieson Becker
source