Meilleur système pour gérer les clés SSH? [fermé]


42

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?

Réponses:


33

J'utilise l' option 3: une paire de clés par ordinateur client , ce qui me semble le plus logique. Voici certaines des raisons:

  • Si un client est compromis, cette clé (et seule cette clé) doit être supprimée des serveurs.
  • Il est suffisamment souple pour décider de ce à quoi je peux accéder depuis où, sans accorder un accès général à tous les serveurs de tous les clients.
  • Très pratique. Il n'y a qu'une clé pour ssh-add, pas de confusion.
  • Facile à configurer et à administrer via l' option 4

L'option 4, c'est bien, mais c'est trop de travail. L'option 3 vous amène à 98% avec beaucoup moins de tracas.


4
Je ne vois pas le but de l'option 4. Cela ne sert à rien.
NiXar

26

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/configfichier:

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

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 jdoemon client local était et le nom de mon ordinateur client local, examplehostl'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.

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

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.


Wow, bonne solution, merci! J'adore la configuration universelle dans ~ / .ssh / config
slacy le

Il a fait ses preuves qu’il était très pratique de séparer les tâches de travail, personnelles et de consultation des serveurs de réseau client ... Je ne veux pas mélanger l’authentification entre eux, mais je veux aussi que ce soit facile pour moi.
Jeremy Bouse

Incroyable! J'aime vraiment celui-ci.
Balu

Je suppose que vous utilisez différentes clés USB pour différents ordinateurs clients. Sinon, à quoi servent les clés séparées si toutes sont stockées au même endroit? En cas de violation, vous devez toutes les révoquer. À moins (et probablement) que quelque chose me manque, cela semble compliquer les choses.
Halil Özgür

@ HalilÖzgür, Oui, je fais du conseil et je ne veux pas toujours utiliser la même clé. Comme la clé USB est cryptée et n'est connectée à aucun ordinateur, sauf si j'en ai besoin pour établir une connexion, le serveur n'est pas inquiet et le mot de passe composé pour déchiffrer le système de fichiers du lecteur est suffisamment long pour simplifier la révocation de clés.
Jeremy Bouse

6

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).


Oui, renommé en "Option 2" appropriée, j'aime bien la règle de "ne jamais copier une clé privée". C'est une bonne règle.
Slacy


1

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.

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.