Bonne pratique pour utiliser la même paire de clés SSH sur plusieurs machines?

J'ai récemment acheté un nouvel ordinateur portable pour le travail, et je me demandais si ce serait une bonne pratique de continuer à utiliser la même paire de clés RSA que j'utilise sur mon ancien ordinateur portable de travail. J'aimerais vraiment ne pas avoir à créer une autre paire de clés pour garder une trace.

Est-ce, d'une manière générale, une pratique acceptable? Étant donné que la paire de clés a une phrase secrète, elle doit être assez sécurisée, tant que mes machines physiques sont sécurisées, non?

Oui, il est sûr tant qu'il est entre de bonnes mains, c'est-à-dire que les machines physiques sont sécurisées. Bien sûr, si un attaquant obtient l'accès et est capable de ssh dans une machine, il peut alors récupérer la clé de cette machine, et utiliser la clé pour d'autres ordinateurs également. Voir ceci pour plus d'informations.

Pour être un peu plus clair par rapport aux autres réponses ici et ailleurs: la "sécurité" n'est aussi sûre que la sécurité de la clé privée. Si quelqu'un peut accéder à vos clés privées, celles-ci peuvent éventuellement être envoyées par e-mail ou copiées sur un périphérique USB. Ensuite, la clé privée copiée pourrait être utilisée par une autre personne.

Tant que la clé privée se trouve dans un système sécurisé, il n'y a aucun problème à la faire passer sur plusieurs machines.

Mais une chose que je dirai: ne copiez pas une clé privée sur un système distant. Essayez de vous fier à l'agent SSH (ssh-agent ou pageant) et au transfert d'agent. Si vous avez une clé privée sur un système distant, assurez-vous que ce n'est pas la même clé utilisée pour accéder au système.

Une seule clé sur plusieurs machines réduit certainement la quantité de clés qu'un administrateur système doit gérer. J'ai cinq machines à partir desquelles je pourrais travailler (généralement environ trois très actives, mais une pourrait être en réparation, une autre à usage très occasionnel). Si une entreprise avait huit personnes comme moi, cela fait 40 clés à administrer au lieu de 8.

Pourtant, le problème qu'Arcege a assez intelligemment souligné, bien qu'indirectement, est que si une seule machine est compromise ou même disparaît pendant une courte période de temps, cela signifierait que je n'aurais plus accès à aucune machine (comme ma clé pour toutes mes machines devraient être abaissées). Certes, la commodité de pouvoir retirer une seule clé d'un ordinateur portable compromis ou volé et de pouvoir continuer à travailler à partir d'une autre machine vaut la peine de gérer plusieurs clés.

Dans un exemple encore plus extrême, imaginez que je suis l'administrateur système et que j'ai un ordinateur portable volé ou piraté. Ma clé doit être retirée mais j'ai besoin d'accéder à tous les systèmes pour le faire. Bien qu'il soit techniquement possible de remplacer et de supprimer en une seule session, lorsque vous essayez de vous déplacer rapidement et de couvrir toutes ses bases, cela complique considérablement le scénario d'urgence.

D'un autre côté, si j'ai des clés uniques pour chaque poste de travail, si je peux accéder à un autre poste de travail, je peux rapidement et efficacement exclure la clé compromise, sans risquer de me bloquer.

En approfondissant l'approche des clés SSH en matière de sécurité, il est clair que pour une sécurité réelle, nous devrions tous utiliser les deux:

• ce que nous avons (clés SSH)
• ce que nous savons (mot de passe pour le serveur)

L'exigence de mot de passe couvre à la fois l'accès au serveur et un mot de passe pour la clé. Le facteur de tracas augmente mais au point où nous avons tous les trois en place (clés SSH, mot de passe d'accès à la clé SSH, mot de passe du serveur) à ce moment-là, il n'y a plus un seul point de défaillance . Un mot de passe de serveur partagé protège également votre équipe contre un mot de passe de clé SSH très faible (normalement, nous n'avons aucun contrôle sur le niveau de mot de passe généré par nos collègues - et un administrateur de mot de passe dans une situation d'entreprise où j'ai accès aux outils d'audit de mot de passe que je peux vous dire même ceux qui devraient mieux savoir créent parfois des mots de passe terriblement faibles).

Un attaquant devrait être déterminé et une attaque réussie pourrait prendre des mois, voire des années. En modifiant le mot de passe du serveur de temps en temps (tous les six mois environ, mot de passe du serveur partagé avec un système de niveau entreprise comme LastPass - rappelez-vous qu'il existe également des clés SSH), à ce stade, vos serveurs bénéficient d'une sécurité raisonnable (car personne ne peut combiner un SSH chaud clé avec un ancien mot de passe pour pénétrer).

Il faut penser à l'accès illégal aux initiés (Edward Snowden vient à l'esprit, Ashley Madison hack vient en deuxième position) comme un risque principal. Ce n'est qu'en utilisant à la fois des clés et des mots de passe qu'il serait possible de vraiment ralentir un initié.

Autre que la méthode chinoise ancienne: les enterrer vivants lorsque leur travail est terminé.

Après l'enterrement, il a été suggéré que ce serait une grave violation si les artisans qui ont construit les appareils mécaniques et connaissaient ses trésors devaient divulguer ces secrets. Par conséquent, une fois les funérailles terminées et les trésors cachés, le passage intérieur a été bloqué et la porte extérieure abaissée, piégeant immédiatement tous les ouvriers et artisans à l'intérieur. Personne ne pouvait s'échapper.

Pour les clés d'utilisateur - oui, si vous utilisez une phrase de passe sécurisée et que vous avez créé la clé sur un système sans failles de sécurité ssh.

Pour les clés de serveur: non.

Je dirais que c'est une bonne habitude d'avoir des clés différentes pour différents groupes, par exemple: travail, domicile, open_source_project.

Plus vous ajoutez de clés, plus il est complexe de les gérer.