Un système de distribution de clés publiques SSH


26

Nous avons de nombreux systèmes différents qui sont gérés par plusieurs personnes. Nous avons choisi d'utiliser l'authentification par clé publique SSH pour accéder à ces systèmes. Cela fonctionne très bien, car il n'est pas nécessaire de gérer ou de partager les mots de passe des comptes administratifs, pas besoin de mémoriser les mots de passe des différents systèmes (uniquement la phrase secrète de votre clé privée), pas besoin d'interaction (saisie du mot de passe) avec chaque commande à distance .

Le problème est que les clés publiques installées sur les systèmes doivent être gérées d'une manière ou d'une autre. Les gens vont et viennent, les clés peuvent être compromises, les responsabilités changent (une personne autorisée à entrer dans un système aujourd'hui peut être autorisée à en accéder à un autre demain). Actuellement, nous le gérons en modifiant manuellement les fichiers ~ / .ssh / authorized_keys sur chaque compte qui en a besoin, mais c'est beaucoup de travail et sujet aux erreurs.

Existe-t-il un outil prêt à gérer les clés publiques dans un tel scénario? Avez-vous vos propres solutions? Ou bien cette idée de gérer des systèmes de cette façon est-elle viciée?


Je ne peux pas vraiment répondre à votre question, mais quand je l'ai lu, je pouvais juste l'entendre crier pour une sorte de système de base de données.
John Gardeniers du

En effet, je peux voir une place pour une base de données sur le 'backend' (le 'serveur de clés'), bien que je préfère limiter l'accès à la base de données et faire distribuer les clés sur le canal SSH. Ne pas ouvrir d'autres canaux de communication sur les systèmes gérés. En fait, je me sens capable de mettre en œuvre un tel outil / système moi-même, bien que je préfère quelque chose de prêt et d'efficacité prouvée.
Jacek Konieczny

Réponses:


18

Comme déjà mentionné par pulegium, tout logiciel de gestion de configuration générique comme Puppet , Chef , Bcfg2 ou cfengine pourrait accomplir la tâche.

Puisque le fichier authorized_keys n'est pas si compliqué, vous pouvez également utiliser rsync ou un (D) SCM comme git ou hg pour gérer ce fichier. Vous avez le fichier "maître" sur l'un de vos serveurs et le servez via rsync / git / hg /…. Sur tous les autres serveurs, vous exécutez une tâche cron qui récupère périodiquement la copie principale (si elle a été modifiée) et la copie à l'emplacement local correct. Heck, cela fonctionnerait même avec HTTP ou FTP pur.

L'essentiel est: Avoir une copie "principale" de votre fichier authorized_keys et le mettre à jour. Laissez les «clients» (les ordinateurs, qui devraient avoir le fichier de clés autorisé actuel) le récupérer à partir de votre serveur maître et le déployer localement.


1
Nous utilisons confortablement des marionnettes pour gérer environ 200 serveurs Linux (les clés de pub ne sont qu'un fichier à appliquer en tant qu'attribut d'un utilisateur).
ForgeMan

1
J'accepterai cette réponse car il semble que je ne vais pas aller mieux. Il me semble que les choix sont les suivants: 1. Garder les choses telles qu'elles sont maintenant 2. Construire sa propre chaîne d'outils pour gérer les fichiers de clés autorisées 3. Utiliser un outil générique existant pour gérer les serveurs, comme Puppet ou Chef… bien que ces outils semblent trop gros pour cette tâche simple. 4. Utilisez un autre mécanisme d'authentification / autorisation (comme Kerberos)… bien que cela semble aussi un outil trop sophistiqué pour une tâche simple Merci.
Jacek Konieczny

ce système est aussi sécurisé que le canal par lequel la copie principale est tirée.
yrk

1
Ansible est un système CM très léger qui a un module pour nettoyer les fichiers de clés autorisés sur ssh. Voir ansible.cc/docs/modules.html#authorized-key
RS

11

Il existe un correctif disponible pour OpenSSH qui lui permet d'utiliser les clés publiques d'un serveur LDAP, mais cela n'a vraiment de sens que si vos vérifications d'authentification / de compte sont également effectuées par rapport à ce serveur LDAP (c'est ainsi que mon environnement est configuré). De plus, il est aussi sécurisé que votre configuration LDAP (vous voulez donc utiliser SSL et vérifier les clés).

Voir http://code.google.com/p/openssh-lpk/ pour le correctif et plus de détails. Je ne connais pas de système d'exploitation livré avec ce correctif par défaut, mais si vous exécutez FreeBSD, il s'agit d'un correctif facultatif si vous utilisez OpenSSH à partir des ports.


1
Incidemment, l'utilisation de pam_ldap vous permet également de résoudre le problème "quelqu'un autorisé à accéder à la machine A aujourd'hui peut ne pas être autorisé à y accéder demain" - lisez pam_ldap si vous êtes intéressé par cet aspect ...
voretaq7

5

je lance une solution très simple, qui fait de même avec les règles de pare-feu

exemple de fichier hosts.conf:

192.168.0.1
192.168.2.99
192.168.2.100

distribuer.sh:

#!/bin/bash
for d in `cat ./hosts.conf`; do
  echo "copying to $d ...";
  scp /root/.ssh./authorized_keys root@$d:/root/.ssh./authorized_keys
done;

c'est toute la magie :-)


5

Je vérifie actuellement SSH KeyDB . Il est censé faire exactement cela, administrer les rôles, les serveurs et les utilisateurs, distribuer les clés d'utilisateur, rassembler les clés d'hôte, etc. Il a même quelque chose appelé "emplacements".

Je n'ai pas encore tout résolu et je ne sais pas si cela fonctionne pleinement. Le code est cependant en python et semble assez gérable, il ne devrait donc pas être trop difficile de le dépoussiérer et de le faire fonctionner.


1

Je ne sais pas ce que vous entendez par beaucoup, je ne sais pas non plus si vous êtes prêt à changer, mais Kerberos est le droïde que vous recherchez. Cela résoudra vos problèmes avec élégance et authentifiera les personnes et les machines.


1

Vous avez deux (qui se transforment généralement en 3) différents problèmes que vous essayez de résoudre:

  • Authentification (qui êtes-vous?)
  • Autorisation (êtes-vous autorisé à accéder à ce serveur?)
  • Audit (qu'avez-vous fait?)

L'authentification par clé publique est un moyen correct de s'authentifier parfois, mais ne traite pas du tout de l'autorisation. Je n'aime pas l'authentification par clé publique, car il est très facile de faire des compromis (en particulier en interne) à moins d'avoir de bons contrôles en place.

C'est là que des solutions comme Kerberos entrent en jeu. Dans le monde Windows, Active Directory résout ce problème. Dans le monde Unix, les choix sont nombreux, ce qui est à la fois une bonne et une mauvaise chose.

Je voudrais découvrir le projet Red Hat FreeIPA , qui est un ensemble de logiciels qui facilite la mise en service rapide d'un système Kerberos / LDAP / DNS de type AD.


Je comprends la différence entre l'authentification, l'autorisation et l'audit. Et les `` touches_autorisées '' de SSH fournissent à la fois des données d'authentification et d'autorisation. C'est loin d'être parfait, mais c'est simple. Et la simplicité est souvent un gros avantage, également en matière de sécurité. Kerberos, avec son infrastructure compliquée, peut échouer en matière de sécurité de plusieurs façons que ssh avec ses fichiers authorized_keys. Cependant, cela ne signifie pas que l'un ou l'autre est plus sûr.
Jacek Konieczny

La gestion des fichiers authorized_keys est np pour une poignée de serveurs, mais vous atteignez rapidement un point où c'est impossible à gérer. Je n'essayais pas de dire que c'est une "mauvaise" solution. De même, les complexités de Kerberos sont inappropriées pour deux serveurs ... mais l'investissement dans la conception / implémentation de kerberos en vaut la peine dans un environnement plus large.
duffbeer703

1

Vous pouvez utiliser Bcfg2 avec des comptes bcfg2 pour distribuer authorized_keys. En prime, vous aurez la possibilité de contrôler les utilisateurs et les groupes.

Bcfg2 permet également une maintenance sans douleur /etc/ssh/ssh_known_hostsavec SSHbase .


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.