SSH: utilisez-vous une paire de clés privée / publique pour chaque machine distante? Ou une seule paire pour tous?

Lorsque vous souhaitez disposer de connexions ssh basées sur une clé publique pour plusieurs machines, utilisez-vous une clé privée et placez la même clé publique sur toutes les machines? Ou avez-vous une paire de clés privée / publique pour chaque connexion?

J'utilise une clé par ensemble de systèmes qui partagent une frontière administrative commune. Cela limite le nombre de machines qui sautent si une clé est compromise, tout en n'écrasant pas complètement ma capacité à stocker et gérer plusieurs milliers de clés. Des mots de passe différents sur chaque clé signifient que même si toutes vos clés privées sont volées et qu'une clé est compromise, les autres ne descendent pas dans les toilettes avec. De plus, si vous faites quelque chose de stupide (comme copier une clé privée sur une machine non fiable), encore une fois, vous n'avez pas besoin de tout ressaisir, juste les machines associées à cette clé.

La clé publique n'a pas beaucoup d'importance, car, par définition, elle peut être rendue publique. Le seul problème est donc la confidentialité de vos clés privées. Ils sont sur votre propre machine, et tous ensemble, donc si l'un est compromis, il est probable qu'ils seront tous compromis. Par conséquent, plusieurs paires de clés représentent un travail supplémentaire pour le même effet.

La seule fois où j'utiliserais des clés différentes est pour différents comptes ou différents rôles, qui par définition ne devraient pas avoir un chevauchement complet dans l'accès.

Si je comprends bien, chaque serveur aura sa propre clé publique.

Pour un utilisateur donné , vous pouvez générer une clé et l'utiliser partout, tant que la clé privée est répliquée sur tous les hôtes initiateurs. (Cela se produirait automatiquement via les répertoires de départ montés sur le réseau et un système d'authentification basé sur les répertoires comme OpenLDAP, car l'utilisateur sera toujours "le même", quel que soit le poste de travail à partir duquel il se connecte.)

En dehors d'un système utilisateur basé sur un annuaire, je pense que c'est une mauvaise idée d'utiliser les mêmes clés partout - vous vous retrouvez avec une nette réduction de la sécurité du système, car quiconque peut obtenir une clé de n'importe quel poste de travail peut ensuite s'authentifier comme cet utilisateur au serveur distant.

Une autre alternative, utilisée par plusieurs grandes sociétés (et je suis sûr que les petites aussi) est de ne jamais autoriser un "utilisateur" à utiliser des clés pré-partagées, mais plutôt de se connecter ensuite à une boîte "jump" ou "hub" , suà l'utilisateur de connexion approprié, puis SSH à partir de là vers les serveurs dont ils ont besoin pour gérer.

De plus, si vous utilisez un système de gestion tel que la plate-forme HP Server Automation, l'administration à distance des serveurs gérés devient un processus plus simplifié.

Comme d'autres l'ont dit, bien que l'idée de plusieurs paires de clés puisse sembler plus sûre, s'il y a une chance qu'elles soient utilisées de manière à ce qu'elles soient toutes au même endroit, c'est juste plus compliqué et pas plus sûr. Des phrases de passe multiples le rendraient plus sûr mais aussi un gros casse-tête en essayant de se rappeler quelle phrase de passe va avec quelle clé et quelle clé va avec quel serveur.

La réponse la plus raisonnable pour moi serait celle où il a été suggéré de le faire UNIQUEMENT si cela implique des rôles administratifs distincts sans trop de chevauchement. Tels que cela pourrait être des personnes différentes gérant les différents rôles, ou sur différents postes de travail ou autre. Dans ce cas, vous avez de toute façon des choses plus uniques à gérer pour chaque rôle différent, donc c'est plus justifiable.

Pour faciliter la gestion de plusieurs serveurs compatibles SSH, vous souhaiterez peut-être consulter cssh . Vous pouvez combiner cssh avec des clés SSH avec mot de passe pour améliorer considérablement votre capacité à gérer plusieurs serveurs simultanément.