Est-il totalement sûr de publier une clé publique ssh?
J'utilise une clé RSA pour me connecter à des serveurs distants avec ssh. Et je garde mes fichiers dot sous contrôle de version dans un endroit accessible au public afin de pouvoir rapidement configurer de nouveaux serveurs pour qu'ils fonctionnent comme je le souhaite.
Pour l'instant, je n'ai pas mon répertoire .ssh sous contrôle de version. Mais cela économiserait une étape si je pouvais conserver .ssh/authorized_keys dans le référentiel dotfile.
C'est juste une clé publique. Ma clé privée se trouve uniquement sur les machines clientes de confiance en ma possession, bien sûr. J'en ai fait une clé RSA 4096 bits car cela semble être le meilleur équilibre entre une large compatibilité avec les versions sshd courantes et la sécurité.
Ma question est donc la suivante: y a-t-il un problème de sécurité avec la publication publique de la clé publique? Personne ne parcourt régulièrement mon dépôt de fichiers dot, mais ce n'est pas un secret et toute personne intéressée pourrait les lire.
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
Clés privées sont secrètes, elles ne doivent être accessibles qu'au propriétaire de ladite clé privée.
Pour ramener ce point à la maison, repensez à chaque site Web HTTPS que vous avez déjà visité. Dans chaque cas, dans le cadre de 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 verrouillage verte sur votre barre d'adresse, vous pouvez trouver la clé publique de ce site Web (si vous la consultez sur HTTPS)
*.stackexchange.com
Modulus (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
Exponent (24 bits):
65537
D'autres exemples de cela peuvent être trouvés sur github.com où ils vous demandent d'attacher une clé publique à votre compte pour l'utiliser avec git clone [email protected]:<user>/<repo>
Vous pouvez réellement 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:
[
{
"id": 18667533,
"key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDraswAp7EbMwyYTzOwnSrsmr3nNMDaDf4e2YVaehLc9w6KN2ommomXZO8/V9N3yINNveGqrcVc9m2NTm04iILJUKd9o25ns8QIG6XSCt9SVx/Xw1J/SXfIWUKuEe0SgmIwVwkk8jetfG/Z7giSiU3dxxC4V9lHQCFgKOKBWGpNbINmqtmBWncX3HJKeXrpSddoePbZZ84IEFr4CWUlqoXyphpxqzpfA9sRpVTtyBPcUSj68j4+gKgEQN65G6LXys3q8BiwWxucci6s34vp4L8jKn7uYh26vLuT1oIbODJphCmpvMH+ABPkNQcFBk4rRLpCEAsoAhmvTk/NjnfZM+nd"
},
{
"id": 21175800,
"key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5tPV481acCZ5wm2E15gXkVRaKCE3lic/O8licyzW+eDE9rPpG4rHRRH9K2ENmstUh5nLEenb0nNhEGnsf3pIJRZ07JXwv16+lsJBSS8+YiWeMBlwo+JNaxwSyUlYUgl1ruogr0nR0KBqsYSWXuG0s2jm2IOV+0B/0fzDR/tiLFLj50+iJ9qCDSk/8fAsXz2xG39KcUcxmCbDXb/qSdESWaZc+pafNRiCcVNfMkKeDViWlzI4VkiTcfVCraHUuYx4jgOBB526dRWSDG9bLchwlJiopgT+k4X/TNe2l01DPwYetwLvY6V8rcPrjjJL8ifRTMSof1zRIoBgJZhRzWc1D"
}
]
L'inverse est vrai de Clés privées qui doivent être sécurisées à tout moment et jamais données à un tiers ou échangées par e-mail sans les chiffrer.
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é avec votre clé publique. Cela signifie également qu'ils peuvent signer des choses en votre nom. C'est TRÈS mauvais si quelqu'un a accédé à 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 des utilisateurs autres que vous ont un accès en lecture.
Est-il totalement sûr de publier une clé publique ssh?
Non, mais vous pouvez quand même le faire sans soucis (beaucoup de gens le font, regardez juste 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 une mathématique ordonnée, 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 à vous inquiéter: il est facile de trouver les facteurs de n lorsque n = 21, mais c'est beaucoup plus difficile lorsque 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 en un temps acceptable. En utilisant la méthode la plus connue, nous serions tous morts depuis longtemps, bien avant que quelqu'un ne trouve les facteurs qui ont constitué votre n .
Il n'est pas complètement 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 différemment de RSA) n'est peut-être plus suffisant. 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 effectuer les calculs nécessaires, il pourrait casser tout le cryptage basé sur ces constantes. 1024 bits nécessitent encore une quantité incroyable de puissance de calcul pour factoriser ou calculer des logarithmes discrets (et des milliards de dollars pour construire des machines pour le faire rapidement), mais cela pourrait valoir la peine pour certains acteurs au niveau de l'État, car il suffit de résoudre quelques problèmes les instances interrompent 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 , mais pas en grande quantité.
(Modifications: clarifié le sens du dernier paragraphe et corrigé l'erreur signalée par RobIII)
Rien n'est "complètement sûr"; la question est de savoir s'il ajoute des risques supplémentaires .
Le protocole SSH envoie la clé publique du client chiffrée , uniquement 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 ces informations supplémentaires? Eh bien, tout cela dépend de la capacité de l'attaquant à rompre le RSA. Prenons deux sous-cas. (Je suppose que le serveur et les clés RSA du client sont suffisamment grands pour être sécurisés en premier lieu - 2 048 bits ou plus.)
L'adversaire a une attaque générale contre RSA qui nécessite la connaissance de la clé publique
Par attaque générale, je veux dire celle qui rompt 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 en temps polynomial) ou en construisant un pratique ordinateur quantique .
Dans ce cas, peu importe que vous publiiez ou non votre clé publique client, car SSH et toutes les autres applications qui utilisent RSA seraient complètement endommagées. Donc pas de risque supplémentaire.
L'attaquant a attaqué un sous-ensemble de clés publiques RSA "faibles"
Il s'agit d'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 réalisée en 2011 auprès de 7,1 millions de clés RSA dans l'Internet public a révélé qu'environ 0,4% des 1024 clés publiques RSA qu'ils voyaient étaient faibles.
Si votre clé publique client est une clé si faible et que vous la publiez, un attaquant qui l'obtient peut être en mesure de le dire et d'exploiter ce fait. Ils pourraient alors se connecter aux serveurs SSH avec lesquels vous utilisez cette clé pour vous authentifier. Ce serait en effet un risque supplémentaire.
Si votre serveur a une clé publique si faible, alors ce serveur n'est pas sécurisé; un attaquant peut espionner les connexions, ce qui leur permet tout de même d'apprendre votre clé publique. Dans ce cas, il n'y a donc aucun risque supplémentaire.
Conclusion
Le risque supplémentaire lié à la publication de la clé publique de votre client SSH est faible mais non nul. Le plus grand risque est que la clé publique de votre client soit faible, causée par un logiciel défectueux. Si vous prévoyez de publier une clé publique client, vous pouvez prendre des mesures pour vous assurer que votre clé n'est pas faible. Par exemple:
- Vérifiez votre clé publique par rapport à un outil de test de clé faible
- Générez la paire de clés de votre client sur un système où vous avez fait preuve de diligence raisonnable 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 les problèmes avec son générateur de nombres aléatoires, SSH ou toute bibliothèque dont SSH dépend.
- Prendre des mesures pour garantir que le système a accès à une bonne source d'entropie. (Sujet compliqué.)
Non, sauf si vous en utilisez un unique par service. Il 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 reliera vos deux comptes ensemble.
J'espère qu'aucun des deux services n'est embarrassant. 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.
Il y a un léger risque de révéler votre identité si votre clé publique contient votre nom d'hôte en tant que commentaire à la fin, par ex. ssh-rsa C4F3B4B3... [email protected]. Si votre nom est assez rare, il peut être possible de vous identifier.
Voir cette question et réponse pour plus de détails: Dois-je publier ma clé SSH publique avec l'utilisateur @ hostname à la fin?
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 pointent quelques vulnérabilités
- qui présentent un risque plus important 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 elle a été conçue. Par exemple, la connaissance de votre clé publique permet votre identification. Cela peut être géré par une clé publique cachée, 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 également être utilisé pour d'autres tâches, cela peut même être fructueux, surtout si nous ne sommes pas sur le côté défensif.
Pour l'instant, je n'ai pas mon répertoire .ssh sous contrôle de version. Mais cela économiserait une étape si je pouvais conserver .ssh/authorized_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 .ssh et vous risquez de ne pas l'exclure du référentiel dotfile et de le publier accidentellement.
Vous pouvez considérer plusieurs menaces. L'une discutée par d'autres répondeurs est celle d'un utilisateur malveillant essayant de casser la clé publique. Une autre menace à considérer est que cet utilisateur malveillant 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 à l'aide des clés de l'utilisateur malveillant, déployant ainsi sa clé publique pour laquelle il possède la paire privée.
Une autre préoccupation concernant le partage de votre clé publique est de savoir si elle a été générée de manière non 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 dériver votre clé privée.
Références:
http://kukuruku.co/hub/infosec/backdoor-in-a-public-rsa-keyhttps://www.cryptologie.net/article/360/how- to-backdoor-diffie-hellman-quick-Explication /
Oui
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 s'affiche également.
Pourquoi?
Pour AES, vous n'avez besoin que de 256 bits car la clé est complètement secrète. Avec RSA, vous donnez à un adversaire des informations (la clé publique), mais il peut être démontré qu'il est toujours aussi difficile à déchiffrer. Mais en factorisant les chiffres, il devient plus rapide et plus rapide que les mots de passe à forçage brutal.
De façon simpliste, deux nombres premiers choisis au hasard sont 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 qu'il est difficile de les factoriser vers les 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
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.
Dans la 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 validez 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 à l'intérieur de votre
.sshdossier vous acceptez ce risque d'erreur humaine potentielle; tu dois faire attention. (Et si cela se produit, il suffit de le supprimer à nouveau pour ne pas le supprimer de l'historique. Pas dans les systèmes les plus populaires d'aujourd'hui. Selon le système de contrôle de version, vous pouvez avoir des difficultés à le purger complètement.) - Selon la façon dont votre référentiel est public et à quoi d'autre vous utilisez cette clé publique, les parties hostiles peuvent éventuellement être en mesure de suivre l'activité effectuée avec cette clé publique et ainsi créer un historique de vos actions. En théorie, vous identifier dans le processus. Plan long.