Question Est-il possible / pratique d'utiliser la même clé privée pour deux serveurs pour la connexion sans mot de passe à partir du même poste de travail / serveur local?


J'ai deux sites Web. Un site Web est un clone de l'autre site Web. Quand j'ai vérifié la sshd_config fichier dans les deux sites, ils sont exactement similaires, sauf une utilise authorized_keys comme identification et autres utilisations Known_keys en tant qu'identification, j'espère que ce n'est pas un problème puisque le chemin d'accès est défini en conséquence, indiquant l'emplacement et le nom de fichier de la clé publique.

Je me demande pourquoi je ne peux pas me connecter avec la même clé privée de la même machine dont la clé publique est installée dans les deux serveurs.

Est-ce qu'il me manque des informations? Ou ce n'est pas possible?


4
2017-07-26 17:11


origine


S'il vous plaît, essayez d'apprendre comment j'ai séparé votre question originale en trois questions distinctes. Poser des questions très pointues et unidimensionnelles comme celles que j'ai extraites de votre question est plus susceptible de donner des réponses utiles. Dans un monde idéal, vous auriez créé Trois Questions de SU, une pour chacune des questions de ma réponse. Avoir beaucoup de questions sur la SU n'est pas un problème, tant que les questions sont bonnes, que les questions répondent bien et que les réponses sont de grande qualité et bien documentées. - allquixotic


Réponses:


Cette question est en fait trois questions distinctes.

Question 1:

c'est possible utiliser la même paire de clés pour l'accès SSH à deux serveurs ou plus?

Réponse 1:

Oui, c'est possible, beaucoup de gens (auto inclus) le font régulièrement. Il n'y a aucune raison pour que ce soit limité à un seul serveur. Nous supposons que vous parlez des paires de clés client et non des certificats de serveur. Une paire de clés client authentifie le client, c’est-à-dire la machine essayant d’accéder à une session SSH. Vous pouvez certainement réutiliser votre paire de clés client, et un serveur ne sera pas plus sûr que votre paire de clés est utilisée sur d'autres serveurs.

Question 2:

Est-ce recommandé utiliser la même paire de clés pour l'accès SSH à deux serveurs ou plus?

Réponse 2:

Cela dépend de qui vous demandez et de la rigueur de votre plan de sécurité. Il y a ajouté des risques d'utiliser le même keypair pour deux hôtes distants ou plus. Ces risques sont au-delà les risques nominaux d'utiliser une paire de clés pour un seul hôte.

Toute personne obtenant votre clé privée (ainsi que la phrase secrète de la clé privée, le cas échéant) pourra y accéder. tout systèmes que votre clé privée authentifie. Le problème revient alors à l'attaquant connaissant les noms d'hôte de tous les serveurs auxquels votre clé privée est authentifiée et les comptes d'utilisateur de chacun des hôtes qui considèrent votre clé publique comme une clé autorisée. Cela augmente les dommages potentiels qui peuvent être causés dans le cas où votre clé privée est volé.

Notez que c'est ne pas un risque d'authentification si quelqu'un obtient seulement votre Publique clé: pour tout ce que vous vous souciez, vous pouvez également mettre votre clé publique SSH sur votre page d'accueil. Vous pouvez même le poster en toute sécurité ici dans votre question uniquement pour des coups de pied et des fous rires, sans aucune implication de sécurité. C'est appelé Publique pour une raison.

Si vous avez des raisons de soupçonner que votre clé privée est loin d'être complètement sécurisée et que vous craignez que les dommages soient significativement plus importants si les deux systèmes étaient compromis, vous pouvez créer deux clés privées. Mais, si vous stockez les deux clés privées sur le même système et qu’elles n’ont pas de phrase secrète, la même phrase secrète ou les mots de passe eux-mêmes sont stockés quelque part (un bout de papier, LastPass, etc.) au même endroit n’ajoute pas réellement de sécurité. Mais si vous utilisez le chiffrement intégral du disque et que vous disposez d’un système client bien sécurisé, le risque de vol de votre clé privée et de votre phrase secrète est relativement faible.

Soit dit en passant, si vous utilisez des clés privées sans aucun mot de passe du tout, il est préférable de ne rien faire de plus que quelques dollars sur vos systèmes. Si vous effectuez des affaires officielles, commerciales ou autres, à mon avis, c'est absolument essentiel utiliser un mot de passe fort et unique n'est pas écrit nulle part


10
2017-07-26 17:27



Merci pour l'explication détaillée, qui a vraiment aidé ma compréhension. Pour résoudre le problème, je pense que je dois télécharger mon sshd_config fichier lui-même. - tough
Que voulez-vous dire par télécharger votre sshd_config? Si vous téléchargez cela, il faudra aller dans le répertoire / etc / ssh et remplacer celui qui existe déjà. Mais vous ne devriez certainement pas stocker de clés publiques / privées ou quelque chose du genre sshd_config... juste faire en sorte que vous ne pensiez pas que c'était le but de ce fichier :) - allquixotic
Par téléchargement sshd_config, Je veux modifier ma question en ajoutant toutes les informations sur le sshd_config ainsi qu'un "ssh -v" après quelques modifications suggérées par vous. J'ai besoin d'une forme de suggestion d'utilisateur connu comme vous, si je devrais demander cela dans une autre question ou éditer celle-ci, je ne veux pas être banni de poser la question ici aussi, comme dans [stackoverflow] (stackoverflow.com) il y a quelques jours. - tough


known_keys et authorized_keys sont des choses complètement différentes.

le authorized_keys fichier est l'endroit où vous devez mettre les clés publiques correspondant aux clés privées que vous allez utiliser pour accéder au serveur. Il est supposé être sur les serveurs dans lesquels vous voulez entrer.

known_keys est un fichier où les empreintes digitales des serveurs distants sont stockées. Vous savez donc que si vous essayez de vous connecter à nouveau, c’est vraiment le serveur que vous prévoyez être. Cela permet d'éviter les attaques de type intermédiaire, où quelqu'un pourrait usurper le nom d'hôte ou l'adresse IP du serveur distant pour voler des informations que vous pourriez fournir en pensant que vous êtes connecté au bon. Ce fichier est automatiquement créé ou mis à jour lorsque vous essayez de vous connecter à un nouvel emplacement. Notez qu'il est lié au fonctionnement de SSH en tant que client. Si vous voyez ce fichier sur votre serveur, vous avez probablement essayé de vous connecter à un autre endroit.


8
2017-07-26 17:25



Votre réponse est utile et résout le plus souvent le problème technique qui empêche l’authentification de l’OP de s’authentifier sur le serveur known_keys fichier. Je + l 'ai fait mais j'espère que ma réponse plus longue sera plus utile dans son ensemble car elle contient des réponses aux trois questions implicites du PO. - allquixotic
Bien sûr @allquixotic, merci. Vous avez vraiment pris du temps pour rédiger une réponse aussi complète. +1 pour toi aussi! :) - Claudio
@Claudio Merci pour la réponse. Maintenant, en ce qui concerne le problème de connexion, j'ai demandé une autre question, avec un fichier de débogage et sshd_config - tough