Question Quelles sont les meilleures pratiques pour gérer les clés SSH dans une équipe?


Je travaille avec de petites équipes (<10) de développeurs et d’administrateurs ayant les caractéristiques suivantes:

  • La plupart des membres de l’équipe ont> 1 ordinateur personnel, dont la plupart sont portables
  • Les membres de l'équipe ont accès à 10 à 50 serveurs, généralement avec sudo

Je pense que cela est assez typique pour la plupart des startups et des groupes informatiques de taille moyenne.

Quelles sont les meilleures pratiques pour gérer les clés SSH dans une telle équipe?

Devez-vous partager une clé unique pour toute l’équipe?

Chaque personne doit-elle avoir sa propre clé sur un compte partagé ("Ubuntu" sur chaque serveur)?

Comptes séparés?

Chaque membre de l'équipe doit-il conserver une clé distincte pour chacun de ses ordinateurs portables ou de bureau?


40
2018-01-23 16:07


origine




Réponses:


Dans mon entreprise, nous utilisons LDAP pour créer un ensemble de comptes cohérent sur toutes les machines, puis nous utilisons un outil de gestion de la configuration (dans notre cas, cfengine). authorized_keys des fichiers pour chaque utilisateur sur tous les serveurs. Les fichiers de clés eux-mêmes sont conservés (avec d'autres informations de configuration du système) dans un référentiel git afin que nous puissions voir quand les clés vont et viennent. cfengine distribue également un sudoers fichier qui contrôle les utilisateurs autorisés à exécuter quoi en tant que root sur chaque hôte, à l'aide des utilisateurs et des groupes du répertoire LDAP.

L'authentification par mot de passe est complètement désactivée sur nos serveurs de production. L'authentification de clé SSH est donc obligatoire. La stratégie encourage l'utilisation d'une clé distincte pour chaque ordinateur portable / ordinateur de bureau / quoi que ce soit, ainsi que l'utilisation d'une phrase secrète sur toutes les clés pour réduire l'impact d'un ordinateur portable perdu / volé.

Nous avons également un hôte bastion utilisé pour accéder aux hôtes du réseau de production, ce qui nous permet d’avoir des règles de pare-feu très restrictives autour de ce réseau. La plupart des ingénieurs ont une configuration SSH spéciale pour rendre cela transparent:

Host prod-*.example.com
     User jsmith
     ForwardAgent yes
     ProxyCommand ssh -q bastion.example.com "nc %h %p"


31
2018-01-23 17:24



C'est une très bonne réponse! Question de suivi: vous utilisez cfengine pour distribuer .authorized_keys. Avez-vous envisagé l'une des méthodes permettant de stocker directement les clés publiques SSH sur votre serveur LDAP? Ils ont principalement besoin de patcher sshd, qui se sent fragile. - Evan Prodromou
J'ai fait quelque chose de similaire avec Chef. - gWaldo
@ EvanProdromou J'ai configuré les clés publiques SSH dans LDAP, mais c'était bien plus fastidieux que nécessaire, étant donné que je devais gérer moi-même les packages SSH à jour, et que quelques vulnérabilités SSH étaient à jour. - Daniel Lawson
Les règles Sudo et les clés SSH peuvent également être placées dans LDAP. Vous pouvez également utiliser SSSD pour le configurer. Liens: sudo.ws/sudoers.ldap.man.html et access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/… - fuero
J'aime ton ProxyCommand ssh -q mordu là! Jamais vu ça. J'hésite à mettre en place un serveur bastion, mais s'il peut être transparent pour les utilisateurs finaux, je suis peut-être tout à fait partisan. Merci Martin! - the0ther


Personnellement, j'aime bien l'idée que chaque membre du personnel ait une clé sur une machine à bastion ssh dédiée sur laquelle il possède un compte utilisateur de base. Ce compte utilisateur a 1 clé ssh qui donne accès à tous les serveurs qu’ils doivent utiliser. (ces autres serveurs doivent également être protégés par un pare-feu afin que seul l'accès ssh de la machine à bastion soit activé)

Ensuite, sur leurs machines de travail quotidiennes, ordinateurs portables, tablettes, etc., ils peuvent faire leur propre choix d'avoir une clé entre eux ou plusieurs clés.

En tant qu’administrateur système sur ce réseau, vous disposez d’un nombre minimal de clés (un par développeur), pouvez facilement surveiller l’accès SSH sur le réseau (comme toutes les routes à travers le bastion) et si le développeur souhaite plusieurs clés ou simplement qu’ils partagent avec leurs machines, ce n’est pas un problème car il n’ya qu’une machine à mettre à jour. (à moins que les bastions des clés ssh ne soient compromises, c’est beaucoup plus improbable que l’une des clés de l’utilisateur)


6
2018-01-23 16:55





J'ai eu le besoin de fournir un accès par clé SSH pour une équipe de 40 développeurs à environ 120 serveurs clients distants.

J'ai contrôlé l'accès en obligeant les développeurs à se connecter via un "hôte de saut" unique. À partir de cet hôte, j'ai généré des clés privées / publiques et les ai déplacées vers les serveurs du client. Si les développeurs avaient besoin d'accéder à un ordinateur portable, ils pourraient utiliser la même paire de clés sur leur système local.


5
2018-01-23 17:22





Personnellement, j'y vais avec chaque utilisateur, alors vous avez instantanément la responsabilité et fixez les restrictions beaucoup plus facilement - je ne sais pas ce que les autres pensent?


2
2018-01-23 16:28





Une approche dont j'ai entendu parler, mais que je n’ai pas utilisée moi-même, est que chaque utilisateur ait un paquet (par exemple, .deb, .rpm) qui contient sa configuration de clé publique ssh, ainsi que tous les fichiers de points qu’ils aiment personnaliser (.bashrc , .profile, .vimrc, etc.). Ceci est signé et stocké dans un référentiel d'entreprise. Ce paquet peut également être responsable de la création du compte utilisateur, ou peut compléter quelque chose d'autre créant le compte (cfengine / puppet etc.) ou un système d'authentification central tel que LDAP.

Ces paquets sont ensuite installés sur les hôtes via le mécanisme de votre choix (cfengine / puppet, etc., travail cron). Une approche consiste à créer un métapaquet qui dépend des packages par utilisateur.

Si vous souhaitez supprimer une clé publique, mais pas l'utilisateur, le package par utilisateur est mis à jour. Si vous souhaitez supprimer un utilisateur, vous supprimez le package.

Si vous avez des systèmes hétérogènes et que vous devez gérer à la fois les fichiers .rpm et .deb, je peux voir cela un peu gênant, bien que des outils comme extraterrestres puissent rendre cela plus facile.

Comme je le dis, je ne l'ai pas fait moi-même. L'avantage de cette approche, à mon sens, est qu'elle complète un système LDAP central et une gestion centralisée des comptes d'utilisateurs, en ce sens qu'elle permet à un utilisateur de mettre facilement à jour son paquet pour inclure son fichier .vimrc, par exemple, sans qu'il soit nécessaire de gérer ce fichier. par des outils tels que la marionnette, à laquelle un utilisateur peut ne pas avoir accès.


2
2018-01-23 20:35





Vous devez choisir la voie la plus sûre et forcer chaque utilisateur à disposer de clés distinctes, et probablement pour chaque périphérique.

Si vous avez des clés partagées entre utilisateurs, même si vous êtes une petite équipe, la révocation d'une clé est un inconvénient pour tous les autres.

Si vous permettez à votre personnel d’avoir une clé pour tous leurs périphériques, ils peuvent choisir les serveurs auxquels ils peuvent se connecter avec ce périphérique. Par exemple, un ordinateur portable peut être limité à un ou deux serveurs, mais le bureau du bureau peut avoir accès à tous les serveurs.


1
2018-01-25 02:35





Il y a quelques années, Envy Labs a écrit un outil appelé Keymaster (en partenariat avec le client Gatekeeper) afin de gérer un tel problème pour les équipes de développement.

Le projet n'a pas eu beaucoup d'amour au cours des deux dernières années, mais est-ce une chose avec laquelle vous pourriez bricoler et peut-être ramener à la vie?

Le repo est disponible dans github: https://github.com/envylabs/keymaster


1
2018-01-30 04:47





Une approche pourrait être de configurer un serveur NIS avec / home share sur NFS. Cela se combinait avec sudo dans les serveurs et permettait uniquement aux utilisateurs de votre choix d'accéder à chaque serveur via la configuration SSH.

Ainsi, chaque membre de l’équipe n’utilisera qu’un seul utilisateur et sa clé pour accéder à tous les serveurs. Sudo et un mot de passe pour les tâches administratives.

Cordialement,

Rafael


-4
2018-01-23 17:06



1) Activer NIS est une faille de sécurité. 2) Avoir un mot de passe et un compte est contraire à la traçabilité et à la responsabilité. - Deer Hunter