J'ai plusieurs ordinateurs clients (ordinateurs portables, ordinateurs de bureau, etc.), je me connecte à plusieurs ordinateurs serveur que je gère et je me connecte à tous via SSH. Je peux imaginer plusieurs schémas de gestion des clés SSH qui auraient du sens, et je suis curieux de savoir ce que font les autres.
Option 1: une paire de clés publique / privée globale.
Je générerais une paire de clés publique / privée et placerais la clé privée sur chaque ordinateur client et la clé publique sur chaque ordinateur serveur.
Option 2: une paire de clés par serveur.
Je générerais une paire de clés sur chaque ordinateur serveur et placerais chaque clé privée sur mes ordinateurs clients.
Option 3: une paire de clés par ordinateur client.
Chaque poste client aurait une clé privée unique et chaque poste serveur contiendrait les clés publiques de chaque poste client à partir duquel je souhaite me connecter.
Option 4: une paire de clés par paire client / serveur
Totalement à la mer?
Lequel de ces est le meilleur? Y a-t-il d'autres options? Quels critères utilisez-vous pour évaluer la bonne configuration?
la source
J'utilise une solution un peu plus compliquée mais très polyvalente, car je souhaite maintenir une séparation entre les clés d'identité SSH utilisées pour mes serveurs de réseau domestique, de bureau, les serveurs de réseau client de consultation et les autres systèmes sur lesquels j'ai un compte.
Cela dit, je travaille presque exclusivement depuis des postes de travail Linux. J'ai donc une clé USB configurée à l'aide du cryptage LUKS. Mon gestionnaire de fenêtres X11 et le démon HAL détectent le lecteur crypté LUKS et demandent le mot de passe de décryptage lors de l'insertion et de la tentative de être monté. En stockant cela sur un lecteur crypté comme je le fais, je ne stocke jamais mes clés SSH sur aucun poste de travail.
J'ai ensuite la configuration suivante dans mon
~/.ssh/config
fichier:Le % d est traduit pour être le répertoire de base de l'utilisateur par OpenSSH et, dans le répertoire ~ / .ssh , j'ai créé keys.d sous la forme d'un lien symbolique vers le chemin du répertoire sur le lecteur USB chiffré correctement monté.
L' expression % l est traduite pour correspondre au nom d'hôte de la machine cliente locale et % u sera traduite sous le nom d'utilisateur du client local.
Cette configuration permet à SSH de rechercher une clé en utilisant 3 expressions différentes. Par exemple, si le nom d'utilisateur de
jdoe
mon client local était et le nom de mon ordinateur client local,examplehost
l'ordre dans l'ordre suivant serait recherché jusqu'à ce qu'il trouve une clé qui existait et qui était acceptée par le serveur distant.Vous pouvez même utiliser l' expression % r pour rechercher une clé spécifique pour le nom d'utilisateur du serveur distant ou % h pour le nom d'hôte du serveur distant, tout comme % u et % l ont été utilisés.
Mise à jour: J'utilise maintenant l'agent gnuPG gpg avec la compatibilité ssh-agent pour lire et utiliser la clé d'authentification de ma carte à puce OpenPGP v2.
la source
J'éliminerais vos deux options 1 (dont je soupçonne qu'une était supposée être l'option 2 ;-) car les clés privées sont des données sensibles et il est logique de les conserver dans le moins d'endroits possible. Personnellement, je ne copierais jamais une clé privée d'un ordinateur à un autre (ni même d'un fichier à un autre sur le même ordinateur), sauf peut-être pour effectuer des sauvegardes. Contrairement à la plupart des clés de chiffrement, si une clé SSH est perdue, ce n'est pas la fin du monde (créez-en une nouvelle, vous ne perdrez aucune donnée).
la source
Option 3 et utilisez quelque chose comme Puppet pour gérer la gestion des clés.
la source
Option 3
Cela vous permet également de contrôler les serveurs auxquels un client peut accéder. Par exemple, si le client X a besoin d'accéder aux serveurs A et B, mais C ou D, vous copiez sa clé publique sur ces hôtes uniquement.
la source