Est-il raisonnable d'avoir plusieurs clés SSH?


44

Jusqu'à présent, j'ai créé une clé SSH distincte pour chaque serveur auquel je dois me connecter (pour chaque objectif, pour être plus précis). Je l'ai fait par sécurité, comme si différents mots de passe étaient attribués à différents sites.

Avoir plusieurs clés SSH améliore-t-il réellement la sécurité? Tous sont utilisés à partir de la même machine, sont situés dans le même ~ / .ssh, la plupart ont même le même mot de passe.

Alors ... devrais-je abandonner tout le système et simplement utiliser une clé SSH pour tout?

[UPDATE 2015-08-05] Github publie votre clé publique et votre client SSH peut envoyer toutes vos clés publiques à chaque serveur, en fonction de la configuration . Ainsi, si vous souhaitez qu'un serveur SSH tiers connaisse votre identité lors de la connexion , vous devez utiliser plusieurs clés SSH, mais à mon avis , il est paranoïaque.


Cette question convient peut-être mieux à la sécurité de l'information .
gerrit le

Réponses:


25

Les clés SSH utilisent la cryptographie à clé publique. Cela signifie que ce que vous installez sur tous ces serveurs n’est que votre clé publique , que vous souhaitez faire connaître au monde entier. Le seul secret réel est votre clé privée que vous gardez verrouillée sur votre propre ordinateur. Alors oui, je dirais que vous perdez votre temps.


20
Je pense qu'il y a des raisons valables d'avoir des clés séparées, et ce ne serait pas une perte de temps. Dans le cas d'une clé compromise, le risque avec ceci est réduit. Le mot de passe devrait être différent pour chaque clé, je suis d'accord.
Jfmessier

Est-il raisonnable d'avoir différentes paires de clés sur différentes machines? Comme différentes instances de systèmes d'exploitation VirtualBox?
Santosh Kumar

1
Cette réponse ignore en profondeur le concept de défense, car elle repose sur "votre clé privée que vous gardez verrouillée sur votre propre machine". Considérez par exemple ce qui se passe si votre ordinateur portable est volé alors que ssh-agent utilise une ou plusieurs de vos clés privées. Si vous avez plusieurs clés, toutes celles qui étaient encore cryptées sont en sécurité. Je n'appellerais pas cela une perte de temps.
Jon Bentley

34

En fin de compte, c'est à vous de décider. Vous devez évaluer votre modèle de menace. Quelle est la probabilité qu'une de vos clés soit compromise? Si une clé est compromise, quelle est la probabilité que les autres clés le soient? Quelles sont les conséquences de la compromission de vos clés? Quel est le coût (y compris le temps) de la gestion de plusieurs clés?

Tenir compte de tels facteurs devrait vous aider à décider si vous avez vraiment besoin de clés séparées. Sur mes machines personnelles de mon réseau local, je n’ai généralement pas besoin de temps supplémentaire pour essayer de gérer plusieurs clés. Cependant, en dehors de mon réseau, j'utilisais différentes clés, chacune avec une phrase secrète unique. Mais ce n'est que mon opinion personnelle.


7
+1 pour "évaluer le modèle de menace". Ceci est juste le point.
Sleske

21

Non, utiliser plus d'une clé n'est pas une perte de temps.

Plus de diversité == moins de risque.

Cette déclaration de Spiff est incorrecte.

Le point est que la clé publique accorde l'accès au détenteur de la clé privée et à personne d'autre.

Le risque d'être concerné ici est l'authentification. Un site non autorisé transfère les demandes d'authentification à votre tâche d'agent. Si vous utilisez une seule clé, alors même si une seule clé est chargée dans votre agent, tous les sites sont ouverts au compte non autorisé .

Cela n'a rien à voir avec les mots de passe , vous pourriez avoir plusieurs clés avec le même mot de passe qui ne ferait aucune différence ici. Parce que ce n'est pas la phrase secrète qui est compromise.

Le voleur transmet les défis à votre agent et peut se connecter à tous les sites pour lesquels des clés sont chargées . Avec différentes clés, une clé chargée -> un site en danger .

Je dis bien pour vous, vous avez choisi la vie privée des autres peuples sur votre propre paresse.

PS la morale de l'histoire est se méfier de la transmission de l'agent


Supposons que je génère trois clés SSH, une pour chacun des trois serveurs auxquels je me connecte régulièrement. Un jour, après m'être déjà connecté aux trois (ce qui signifie que ssh-agent a mis en cache les phrases secrètes des trois clés), puis, selon votre argument, si mon ssh-agent est compromis, les trois connexions sont également compromises. Dans un tel cas, le fait de posséder plusieurs clés SSH ne m'a pas protégé. Ai-je bien compris?
sampablokuper

9

Je pense qu'il existe un bon cas d'utilisation pour plusieurs clés publiques, à savoir si vous avez des clés privées stockées sur des ordinateurs dans différents domaines de confiance. Donc, je garde généralement une clé qui est ma clé "travail" et une autre qui est ma clé "maison", tout simplement parce que la clé privée de mes affaires "maison" n'est pas stockée sur mon ordinateur de travail et inversement.


Excellente réponse, si vous avez différentes machines avec des clés différentes, parfait. Si une (ou plusieurs) machines ont toutes les mêmes clés, eh bien, vous ne vous protégez pas contre tout ce qui est supplémentaire, mais seulement avec une seule clé. Si l'on est compromis, tout le reste sur cette machine l'est aussi.
xréf

3

Je pense que raisonnable peut être considéré sous deux angles différents: sécurité et commodité .

Lorsque nous créons une paire de clés SSH, il nous est demandé de fournir une phrase secrète pour ajouter une couche supplémentaire afin de protéger la clé privée, comme suit:

$ ssh-keygen -t rsa -b 4096 -C 'With_OR_Without_Passwd'
Generating public/private rsa key pair.
Enter file in which to save the key (/Your/HomeDir/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):

Bien qu'il y ait une invite explicite demandant la phrase secrète, certaines personnes (ou beaucoup) se concentrent davantage sur les informations entre parenthèses: (vide pour aucune phrase secrète) et suivent cette suggestion.

La combinaison ou non l' utilisation de plusieurs paires de clés SSH et que concluent ou non passwd supplémentaires , nous avons au moins quatre façons d'aller. Et supposons que toutes les paires de clés et le configfichier sont stockés dans ~/.ssh/.

Considérons maintenant la sécurité en premier.

Le tableau suivant donne un classement simple sur la sécurité (plus le nombre est élevé, plus la sécurité est sûre):

Security     Ways to go
   1         One   SSH key-pair  (NO passwd)
   1         Multi SSH key-pairs (NO passwd)
   2         One   SSH key-pair  (WITH passwd)
   2         Multi SSH key-pairs (WITH passwd) (SAME passwd)
   3         Multi SSH key-pairs (WITH passwd) (DIFF passwds)

Sans mot de passe , si notre système est envahi par quelqu'un, le disjoncteur peut alors obtenir toutes nos clés privées et notre configuration, ainsi que l'authentification des serveurs distants. Donc, dans cette situation, une paire de clés et plusieurs paires de clés sont identiques. Le moyen le plus sûr consiste à utiliser différents mots de passe pour différentes paires de clés ssh.

Alors ne pensons pas à la commodité .

Mais plus de paires de clés et plus de mots de passe rendent également notre vie moins pratique, le tableau suivant donne un classement simple en matière de sécurité (plus le nombre est élevé, plus la sécurité est assurée):

Convenient  Security  Ways to go
   5           1      One   SSH key-pair  (NO passwd)
   4           2      One   SSH key-pair  (WITH passwd)
   3           1      Multi SSH key-pairs (NO passwd)
   2           2      Multi SSH key-pairs (WITH passwd) (SAME passwd)
   1           3      Multi SSH key-pairs (WITH passwd) (DIFF passwds)

Ainsi, dans la situation générale, si nous devons concilier sécurité et commodité en même temps, nous pouvons multiplier les deux scores, et une paire de clés SSH (WITH passwd) est peut-être celle qui convient le mieux.

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.