CaffeineAddiction

2017-02-07 00:58:17 UTC

view on stackexchange narkive permalink

Les clés publiques sont conçues pour le partage, l'accès en lecture et / ou la publication d'une clé publique est très bien

Les clés privées sont secrètes, elles ne devraient être accessible au propriétaire de ladite clé privée.

Pour ramener ce point à la maison, repensez à chaque site Web HTTPS que vous avez visité. Dans chaque cas, dans le cadre du HTTPS, le site vous donne sa clé publique. Donc, non seulement il est sûr de le publier, mais il est prévu qu'il en soit ainsi. Par exemple, si vous cliquez sur l'icône de cadenas vert de votre barre d'adresse, vous pouvez trouver la clé publique de ce site Web (si vous la visualisez sur HTTPS)

  * .stackexchange.comModulus ( 2048 bits): af 46 03 ce c7 13 e6 2e 93 d8 56 91 b1 31 8d 0a 22 c1 f0 eb 4f 5e ef 0d f6 20 32 b9 a4 4e 87 f9 d2 d2 44 51 b0 df 30 50 c9 35 4e 68 19 84 fb 98 33 aa 05 4b 7e fb 57 c5 b6 2e a8 4b 04 ca cf 5e 2e e5 9e 1b ca b7 60 c5 58 2c b0 df c4 6b 0d b1 2c 33 97 73 54 61 2b 9a 1b b1 dc 5d 10 a9 c4 c8 f7 6c e3 55 6e b5 0e 61 3b 35 24 0b 89 1e 32 a2 75 69 4e 97 40 68 ee 23 48 f2 71 9f c7 7e e2 9d 6c 22 55 36 24 64 a4 f0 b6 52 58 5a 9a 44 e7 3b 2a d5 ed 95 63 f8 1d a8 4d 45 9b 5d c2 f2 f9 74 81 06 18 d5 b1 fb b0 7e 5d 50 1f 63 5c a0 73 f5 22 b2 57 64 03 e6 b7 0f 6f b7 58 0b 57 80 56 51 65 9f f5 09 61 63 29 62 4d 30 02 3a 64 10 2d 95 b8 12 36 04 58 c5 d7 1d 95 e2 21 3c b0 b3 93 35 b2 b1 f9 6d 7e 20 66 b2 68 33 e9 50 a8 15 1e 0a 80 9a 3c 19 dd cc 79 35 a8 8c 1b 61 33 5d 12 2f Exposant (24 bits): 65537

D'autres exemples de cela peuvent être trouvés sur github.com où ils vous demandent de joindre une clé publique à votre compte à utiliser avec git clone git@github.com: <user> / <repo>

Vous pouvez en fait vérifier les clés publiques de n'importe quel utilisateur sur github avec l'URL suivante

https://api.github.com/users/<user>/keys

le mien est répertorié comme suit:

  [{"id": 18667533,
"Clé": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDraswAp7EbMwyYTzOwnSrsmr3nNMDaDf4e2YVaehLc9w6KN2ommomXZO8 / V9N3yINNveGqrcVc9m2NTm04iILJUKd9o25ns8QIG6XSCt9SVx / Xw1J / SXfIWUKuEe0SgmIwVwkk8jetfG / Z7giSiU3dxxC4V9lHQCFgKOKBWGpNbINmqtmBWncX3HJKeXrpSddoePbZZ84IEFr4CWUlqoXyphpxqzpfA9sRpVTtyBPcUSj68j4 + gKgEQN65G6LXys3q8BiwWxucci6s34vp4L8jKn7uYh26vLuT1oIbODJphCmpvMH + ABPkNQcFBk4rRLpCEAsoAhmvTk / NjnfZM + e"}, { "id": 21175800, "clé": « ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5tPV481acCZ5wm2E15gXkVRaKCE3lic / O8licyzW + eDE9rPpG4rHRRH9K2ENmstUh5nLEenb0nNhEGnsf3pIJRZ07JXwv16 + lsJBSS8 + YiWeMBlwo + JNaxwSyUlYUgl1ruogr0nR0KBqsYSWXuG0s2jm2IOV + 0o / 0fzDR / tiLFLj50 + iJ9qCDSk / 8fAsXz2xG39KcUcxmCbDXb / qSdESWaZc + pafNRiCcVNfMkKeDViWlzI4VkiTcfVCraHUuYx4jgOBB526dRWSDG9bLchwlJiopgT + k4X / TNe2l01DPwYetwLvY6V8rcPrjjJL8ifRTMSof1zRIoBgJZhRzWc1D »}]

Le contraire qui est vrai de Les clés privées qui doit être sécurisé à tout moment et jamais donné à un tiers ou échangé par e-mail sans chiffrement

Si quelqu'un a accédé à votre clé privée, il a la possibilité d'accéder à n'importe quel appareil ou fichier crypté qui a été protégé par votre clé publique. Cela signifie également qu'ils peuvent signer des choses en votre nom. C'est TRÈS mauvais si quelqu'un a obtenu l'accès à votre clé privée.

Dans de nombreux cas, les clients SSH ne fonctionneront pas s'il est détecté que les autorisations du fichier de clé privée sont telles que les utilisateurs autres que vous ont un accès en lecture.

Je suppose que cela pourrait être amélioré en exposant la raison pour laquelle les clés privées sont privées, etc.

De manière simpliste, deux nombres premiers choisis au hasard constituent la clé privée et multipliés ensemble forment la clé publique.C'est faisable car les nombres premiers sont assez courants.RSA est basé sur l'hypothèse (techniquement non prouvée) qu'il est difficile de les ramener aux deux nombres premiers.

@J.A.K: Pour développer cela, la clé privée n'est pas en fait le produit des deux nombres premiers p et q.C'est l'inverse modulaire de l'exposant de clé publique e sur le module p * q.Les modules p * q et e sont publiés.Si vous pouvez factoriser p * q, vous connaissez p et q et pouvez calculer l'inverse modulaire de e.

Je ne pense pas que la plupart des gens cliquent sur cette page pour comprendre les nuances mathématiques sous-jacentes, car la question porte sur les propriétés de base de ce qu'est une clé publique."La sécurité réside dans ..." aurait été une meilleure formulation, je suis d'accord.Mais je crois que c'est aussi pourquoi RSA-129 a été généré;montrer la dureté de la factorisation d'une manière saisissable

D'accord, mais mon commentaire explique ce que sont le module et l'exposant dans l'exemple d'échange de pile ci-dessus.De plus, le fait que le module ne soit * pas * la clé entière permet de réutiliser le module dans des logiciels comme ssh et de choisir simplement différents exposants, et c'est pourquoi il est probable que les agences à trois lettres soient intéressées à dépenser des milliards de dollars pour factoriserjuste quelques chiffres - s'ils peuvent factoriser un module souvent utilisé, chaque clé publique qui est réellement disponible en public et basée sur ce module est une porte instantanée vers la clé privée.Je pense donc que c'est pertinent pour la question.

@Pascal umm Je pense que vous confondez RSA avec DH.Avec RSA, le module doit être distinct pour chaque paire de clés.Si vous avez le module et les deux exposants, vous pouvez récupérer p et q http://www.di-mgt.com.au/rsa_factorize_n.html.

Eh bien, oui, le point sur la réutilisation s'applique en fait à DH (voir ma propre réponse sur la réutilisation des constantes dans DH - ne devrait pas passer sous silence les détails lorsque je pointe du doigt ... désolé!).Le problème immédiat avec les clés * all * ssh partageant le même module RSA serait que pour calculer la paire de clés lors de la génération d'une nouvelle paire de clés, vous devez accéder à p et q, les facteurs du module n.Donc, si ssh réutilisait le même module pour chaque clé RSA, son code source contiendrait p et q comme constantes.Nous pourrions donc simplement aller chercher p et q dans le code source - pas besoin de calculer (ou de dépenser) quoi que ce soit :-)

Fait intéressant, lorsque je regardais votre réponse sur HTTP (non S), la réponse disait ** "Bien sûr, vous pouvez publier vos clés publiques _et_ vos clés privées, pas de problème" **.

@Pascal: Votre premier commentaire sur la clé privée est ** totalement faux **.L'inverse modulaire de tout entier sur n'importe quel module est ** facilement calculable ** (en temps logarithmique).La clé privée est l'inverse multiplicatif de la clé publique modulo (p-1) * (q-1), et non p * q.p * q est publié, mais (p-1) * (q-1) est difficile à calculer sans connaître p ou q.

@J.A.K .: Voir mon commentaire ci-dessus.Et si quelqu'un s'intéresse réellement à la sécurité, c'est à eux de comprendre suffisamment les mathématiques pour ne pas faire de bêtises.Beaucoup de professionnels de la sécurité qui ne finissent pas par rendre leurs systèmes non sécurisés pour des raisons très naïves d'un point de vue mathématique.

@user21820: Yup - vous avez raison.Comme je l'ai dit, je ne dois pas pointer du doigt et me tromper aussi!La prochaine fois, je vais le chercher au lieu d'essayer de le supprimer de mémoire avant de me faire un idiot ;-) Et désolé, J.A.K.

@Pascal: Aucun idiot n'admettra ses erreurs.En outre, j'ai été amusé que votre réponse réelle n'indique rien de mal à propos de RSA, contrairement à ici.=)

Astuce rapide sur les clés github.Si vous utilisez l'url https://github.com/user.keys, il les rendra prêtes à être placées dans les clés autorisées.

@Pascal Vous n'avez aucune idée de la fréquence à laquelle je gâche ça moi-même;).Le fait que les gens participent en fait un endroit formidable, le reste se réglera.

Out of Band

2017-02-07 01:35:27 UTC

view on stackexchange narkive permalink

Est-il totalement sûr de publier une clé publique ssh?

Non, mais vous pouvez le faire de toute façon sans soucis (beaucoup de gens le font, il suffit de regarder https://sks-keyservers.net/i/ ou https://pgp.mit.edu/)

La raison pour laquelle ce n'est pas complètement sûr est parce que si je connais votre clé publique, je peux, avec un bon morceau de mathématiques, calculer votre clé privée. Votre clé publique contient un grand nombre n qui est essentiellement le produit de deux nombres premiers, et si je trouve ces deux nombres premiers, je peux facilement trouver votre clé privée.

La raison pour laquelle vous n'avez pas inquiétude: il est facile de trouver les facteurs de n quand n = 21, mais c'est beaucoup plus difficile quand n est un nombre de 4096 bits. Aucun mathématicien actuellement vivant ou mort n'a publié un moyen de factoriser un si grand nombre dans un temps acceptable. En utilisant la méthode la plus connue, nous serions tous morts longtemps, bien avant que quiconque ne trouve les facteurs qui composent votre n .

Il n'est pas totalement impossible que quelqu'un trouve un raccourci pour factoriser de grands nombres. Si cela se produit, RSA sera sans valeur. Jusque-là, vous n'avez pas à vous inquiéter.

SSH utilise à la fois RSA (ou un autre schéma de signature) et Diffie Hellman (pour l'échange de clés de session). 1024 bits pour l'échange de clés Diffie Hellmann (qui fonctionne mathématiquement un peu différemment de RSA) pourrait ne plus être assez grand. C'est parce que certaines implémentations ssh (et implémentations ssl, si je me souviens bien) qui utilisent Diffie Hellman réutilisent certaines constantes au lieu de les choisir au hasard et une fois que quelqu'un a construit une machine pour faire les calculs nécessaires, ils pourraient casser tout le cryptage basé sur ces constantes. 1024 bits nécessitent toujours une puissance de calcul incroyable pour factoriser ou calculer des logarithmes discrets (et des milliards de dollars pour construire des machines pour le faire rapidement), mais cela pourrait en valoir la peine pour certains acteurs au niveau de l'État, car il suffit de résoudre quelques problèmes les instances interrompront un si grand nombre de sessions chiffrées. Cependant, 2048 et 4096 bits sont toujours considérés comme sûrs.

Il en va de même pour les clés RSA; Je ne pense pas qu'un nombre de 1024 bits ait encore été pris en compte en public, mais il est probablement là à l'horizon, ce qui signifie qu'il est probablement possible pour les institutions avec de très gros budgets de factoriser des nombres de 1024 bits maintenant , bien que pas en grandes quantités.

(Modifications: Clarification du sens du dernier paragraphe et correction de l'erreur signalée par RobIII)

RSA 1024 bits serait probablement un peu trop proche pour le confort.2048 bits devraient convenir, 4096 bits ajoutent une bonne marge de sécurité (mais pas autant que, par exemple, passer d'AES-128 à AES-256) * contre les attaques actuellement connues du public *.

D'accord.Je vois que le dernier paragraphe est trompeur;Je voulais dire que les clés 2048 et 4096 bits sont également sûres pour RSA alors que les clés 1024 bits ne le sont probablement plus, étant donné que même un effort public / de recherche pourrait bientôt en factoriser une (donc trois agences de lettres sont probablement en avance)

`" Notez que ssh vous permet de choisir entre RSA et Diffie Hellman. "` Je peux me tromper mais les options "RSA1", "DSA", "RSA" (pour RSA2), "ECDSA" et "ED25519" ne sont-elles pas?Corrige moi si je me trompe.

Hmmm, tu as raison.Je me souvenais mal - selon http://security.stackexchange.com/questions/76894/how-does-ssh-use-both-rsa-and-diffie-hellman, il semble que ssh utilise RSA pour ses capacités de signature et Diffie Hellmanpour l'échange de clés - je suppose donc que Diffie Hellman est toujours utilisé comme algorithme d'échange de clés, quel que soit le schéma de signature (RSA1, DSA, ECDSA, ED25519) que vous utilisez.Je modifierai la réponse pour la refléter.

«Aucun mathématicien actuellement vivant ou mort n'a publié un moyen de factoriser un si grand nombre dans un temps acceptable.Je pense que l'utilisateur @PeterShor pourrait ne pas être d'accord avec vous

@SteveCox vrai, mais récupérable avec l'ajout d'un mot."utilisable".Le matériel capable d'exécuter l'algorithme de Shor en temps sous-exponentiel n'existe pas encore.Il est encore un peu de temps loin afaik.

@RobIII, Pascal: "RSA1" n'est pas un schéma de signature, cela signifie "RSA pour SSHv1", où la clé RSA a été utilisée pour _decryption_ - dans le protocole SSHv1 désormais obsolète, le serveur crypterait un défi à votre clé.(C'est pourquoi il ne supportait que RSA, je suppose.) Toutes les autres options sont des clés de signature pour le protocole SSHv2, et oui, SSHv2 prend en charge plusieurs schémas de signature et utilise * DH pour l'échange de clés.

@grawity -Ah - vous ne finissez jamais d'apprendre.C'est pourquoi j'adore stackexchange.Merci!

Luis Casillas

2017-02-07 07:56:12 UTC

view on stackexchange narkive permalink

Rien n'est "complètement sûr"; la question est de savoir si cela ajoute des risques supplémentaires .

Le protocole SSH envoie la clé publique du client chiffrée , seulement après avoir négocié une clé de chiffrement de session symétrique avec le serveur. Ainsi, un adversaire qui écoute la connexion n'apprend pas la clé publique du client. Cela signifie que sa publication donne à l'adversaire une information supplémentaire qu'il n'aurait pas autrement.

Mais que peut faire l'adversaire avec cette information supplémentaire? Eh bien, tout dépend de la capacité de l'attaquant à casser le RSA. Considérons deux sous-cas. (Je suppose que les clés RSA du serveur et du client sont suffisamment grandes pour être sécurisées en premier lieu — 2048 bits ou plus.)

L'adversaire a une attaque générale sur RSA qui nécessite une connaissance de la clé publique

Par attaque générale, j'entends celle qui brise RSA quelle que soit la clé que vous utilisez. Par exemple, ce serait quelque chose comme un algorithme efficace pour résoudre le problème RSA (par exemple, un algorithme de factorisation polynomiale en temps premier) ou en construisant un ordinateur quantique pratique.

Dans ce cas, peu importe que vous publiiez ou non la clé publique de votre client, car SSH et toutes les autres applications qui utilisent RSA seraient complètement interrompues. Donc pas de risque supplémentaire.

L'attaquant a une attaque contre un sous-ensemble de clés publiques RSA "faibles"

C'est un problème réel. Il existe certains systèmes qui, en raison d'algorithmes de génération de clés défectueux ou de générateurs de nombres aléatoires défectueux, choisissent des clés RSA qui sont en fait vulnérables aux attaques. L'exemple le plus notable est que la distribution Debian GNU / Linux a été livrée avec un générateur de nombres aléatoires faible pendant près de deux ans (septembre 2006 au 13 mai 2008). Une enquête de 2011 portant sur 7,1 millions de clés RSA sur l'Internet public a révélé qu'environ 0,4% des 1024 clés publiques RSA vues étaient faibles.

Si la clé publique de votre client est une clé si faible et que vous la publiez, alors un attaquant qui l'obtient pourra peut-être le dire et exploiter ce fait. Ils pourraient alors se connecter aux serveurs SSH sur lesquels vous utilisez cette clé pour vous authentifier. Ce serait en effet un risque supplémentaire.

Si votre serveur a une clé publique aussi faible, alors ce serveur n'est pas sécurisé; un attaquant peut écouter les connexions, ce qui leur permet quand même d'apprendre votre clé publique. Donc, dans ce cas, il n'y a pas de risque supplémentaire.

Conclusion

Le risque supplémentaire lié à la publication de la clé publique de votre client SSH est faible mais pas nul. Le plus grand risque est que la clé publique de votre client soit faible, causée par un logiciel défectueux. Si vous allez publier une clé publique client, vous souhaiterez peut-être prendre des mesures pour vous assurer que votre clé n'est pas faible. Par exemple:

Comparez votre clé publique avec un outil de test de clé faible
Générez votre paire de clés client sur un système où vous avez terminé diligence pour vous assurer qu'il ne vous donnera pas de clés faibles. Par exemple:
- Appliquez tous les correctifs de sécurité à votre système d'exploitation, en particulier ceux qui résolvent des problèmes avec son générateur de nombres aléatoires, SSH ou toute bibliothèque dont dépend SSH.
- Prenez des mesures pour vous assurer que le système a accès à une bonne source d'entropie. (Sujet compliqué.)

Vous pouvez également recommander la rotation des clés comme atténuation.Avez-vous des conseils sur l'outillage pour rendre cela facile?Par exemple, après avoir ajouté une nouvelle clé privée, existe-t-il des outils pour vous avertir côté client chaque fois que vous utilisez une ancienne clé pour vous connecter à un site, afin que vous sachiez que vous devez toujours modifier le fichier authorize_keys sur ce serveur?

Quoi qu'il en soit +1, c'est la meilleure réponse car elle examine en fait ce que les risques potentiels existent et n'existent pas.

user541686

2017-02-07 12:54:40 UTC

view on stackexchange narkive permalink

Non, sauf si vous en utilisez un par service. Cela permet aux attaquants de vous identifier.

Si vous utilisez la même clé publique pour le service A et le service B et que votre clé publique est divulguée pour les deux, cela va croiser vos deux comptes ensemble.

J'espère qu'aucun des deux services n'est gênant. Mais même dans ce cas, cela donnera à l'attaquant une meilleure piste pour déterminer quel (s) compte (s) pirater un jour, s'il veut vous attaquer.

L'identification est à peu près le seul risque réel de «fuite» d'une clé publique.

Démo sur https://blog.filippo.io/ssh-whoami-filippo-io/

AilihddlssCMT Freaky.

@Mehrdad Belle trouvaille.Il m'a fallu un moment pour réaliser que cela m'avait donné un "passé" cependant.Il faisait écho aux clés publiques "ci-dessous", mais je ne les ai pas trouvées.Finalement réalisé que ce qu'il avait fait écho n'était rien, comme dans aucun essayé.

whirlwin

2017-02-07 14:00:21 UTC

view on stackexchange narkive permalink

Il y a un léger risque de révéler votre identité si votre clé publique contient votre nom d'hôte comme commentaire à la fin, par exemple ssh-rsa C4F3B4B3 ... johndoe@nomentreprise.com . Si votre nom est assez rare, il peut être possible de vous identifier.

Voir cette question Réponse d'& pour plus de détails: Dois-je publier ma clé SSH publique avec user @ hostname à la fin?

Cela fonctionne pour ssh auth même si vous supprimez le nom d'hôte à la fin.

Oui, cela fonctionne car ce n'est qu'un commentaire qui peut être supprimé.Mais si vous oubliez de le retirer vous-même avant de le donner, cela peut être un problème.

Mon nom d'hôte était 2013-iMac.local, ce qui n'est pas très personnel, mais cela aurait pu l'être.

peterh - Reinstate Monica

2017-02-07 23:57:12 UTC

view on stackexchange narkive permalink

Oui, mais ...

Si votre sécurité repose sur le caractère privé de la clé publique, vous faites quelque chose de sous-optimal. Ce n'est pas pour cela que le chiffrement asymétrique est conçu.

Toutes les réponses précédentes indiquent certaines vulnérabilités

qui présentent un plus grand risque si votre clé publique est connue,
ou ils montrent une défense supplémentaire que vous avez si elle est gardée secrète.

Dans les deux cas, la vraie raison est que vous n'utilisez pas la clé publique pour laquelle Cela a été conçu. Par exemple, la connaissance de votre clé publique rend possible votre identification. Cela peut être géré par pubkey masqué, mais cela peut être mieux fait si vous utilisez un mécanisme supplémentaire (par exemple, une couche de chiffrement supplémentaire avec des paires de clés aléatoires générées automatiquement par session) pour cette tâche.

Mais, tout peut être utilisé aussi pour d'autres tâches, cela peut même être fructueux, surtout si nous ne sommes pas du côté défensif.

mkrieger1

2017-02-07 21:16:20 UTC

view on stackexchange narkive permalink

Pour le moment, je n'ai pas mon répertoire .ssh sous contrôle de version. Mais cela économiserait une étape si je pouvais garder .ssh / allowed_keys dans le référentiel dotfile.

Même s'il devrait être sûr de rendre la clé publique publique, je ne pense pas que ce soit une bonne idée:

La clé privée est également stockée dans le répertoire .ssh et il y a un risque que vous ne preniez pas soin de l'exclure du référentiel dotfile et de la publier accidentellement .

shellster

2017-02-08 20:31:49 UTC

view on stackexchange narkive permalink

Un autre problème lié au partage de votre clé publique est qu'elle n'a pas été générée de manière sécurisée. De nombreux articles ont été publiés sur la manière dont les clés RSA et Diffie Hellman peuvent être détournées, mais semblent par ailleurs parfaitement normales. Dans ce scénario, fournir votre clé publique donnerait à un attaquant toutes les informations dont il avait besoin pour obtenir votre clé privée.

Références:

http://kukuruku.co/ hub / infosec / backdoor-in-a-public-rsa-key https://www.cryptologie.net/article/360/how-to-backdoor-diffie-hellman-quick-explanation/

Marcelo Bielsa

2017-02-09 18:57:13 UTC

view on stackexchange narkive permalink

Vous pouvez envisager plusieurs menaces. L'un des autres répondants est celui d'un utilisateur malveillant qui tente de déchiffrer la clé publique. Une autre menace à considérer est cet utilisateur malveillant qui remplace vos clés publiques par les siennes. S'il change les clés et que vous ne le remarquez pas, vous pouvez configurer un système utilisant les clés de l'utilisateur malveillant - déployant ainsi sa clé publique pour laquelle il possède la paire privée.

J.A.K.

2017-02-07 14:18:17 UTC

view on stackexchange narkive permalink

Si RSA fonctionne comme prévu, cela ne devrait pas être un problème de sécurité. Cela peut révéler un peu d'informations sur votre identité, mais rien de cette question ne montre également.

Pourquoi?

Pour AES, il vous suffit de 256 bits car la clé est complètement secrète. Avec RSA, vous donnez à un adversaire des informations (la clé publique), mais cela peut montrer qu'il est toujours aussi difficile à déchiffrer. Mais la factorisation des nombres devient plus rapide que les mots de passe forcés.

Simplement, deux nombres premiers choisis au hasard sont la clé privée, et multipliés ensemble forment la clé publique. (Ceci est faisable car les nombres premiers sont assez courants). RSA est basé sur l'hypothèse qu'il est difficile de les ramener aux deux nombres premiers. Il y a eu beaucoup de progrès dans les algorithmes de factorisation des nombres, et si des ordinateurs quantiques à part entière arrivent, l'algorithme de Shor sera la fin de RSA

Veuillez ne pas voter sans laisser un commentaire sur la raison.

wberry

2017-02-10 23:03:44 UTC

view on stackexchange narkive permalink

En termes de théorie des systèmes PKI, non. Le système est conçu pour être «sûr», ou plus précisément pas plus faible , lorsque l’algorithme et la clé publique sont connus du monde entier.

En pratique, il pourrait y avoir une certaine exposition à vous pour d'autres raisons. En bref, ne compromettez pas votre propre sécurité par des erreurs; et il est préférable de créer des paires de clés distinctes pour chaque objectif individuel.

Si vous oubliez et commettez accidentellement la clé privée, ou un certificat de révocation, et que quelqu'un le voit, ils pourraient être utilisés contre vous. En validant quoi que ce soit dans votre dossier .ssh , vous acceptez ce risque d'erreur humaine potentielle; tu dois faire attention. (Et si cela se produit, le simple fait de le supprimer à nouveau peut ne pas le supprimer de l'historique. Pas dans les systèmes les plus courants d'aujourd'hui. Selon le système de contrôle de version, vous pouvez avoir des difficultés à le purger complètement.)
En fonction à quel point votre référentiel est public, et pour quoi d'autre vous utilisez cette clé publique, les parties hostiles pourraient éventuellement être en mesure de suivre l'activité effectuée avec cette clé publique et ainsi construire un historique de vos actions. En théorie, vous identifier dans le processus. Plan de loin.