Y a-t-il un risque de sécurité à créer des clés publiques/privées à la racine et à ajouter la clé publique au répertoire Github ?

Qu'en est-il de l'utilisation d'un VPN pour accéder à votre réseau professionnel/domestique lorsque vous voyagez ? Tout serait protégé, maintenu à l'intérieur de votre réseau professionnel, accessible de n'importe où tant que vous utilisez votre client VPN pour vous connecter, ainsi qu'extensible aux personnes que vous jugez dignes en leur donnant accès à votre VPN.

Alors la réponse correcte ne serait-elle pas "Créer une paire de clés ssh RSA de 4096 bits" ? C'est ce que Github recommande après tout. Ils le recommandent probablement pour une raison. Après tout, des états comme la Chine, la Russie et les USA aimeraient bien trafiquer une grande partie du code de nombreux projets open source sur git hub. Je ne serais pas surpris qu'ils recommandent cette longueur de clé parce que l'un de ces gouvernements a déjà essayé quelque chose de moins honorable. En tant que tel pourquoi le downvote ?

Le downvote est pour la fausse déclaration "Si la clé publique est accessible à toute personne en qui vous n'avez pas confiance, c'est un risque de sécurité." Si vous avez révisé votre réponse pour qu'elle se concentre simplement sur la nécessité d'une clé publique, vous avez été déçu. fort clé, je serais enclin à l'inverser.

Une meilleure version serait-elle la suivante : "Si la clé publique est accessible à une personne en qui vous n'avez pas confiance, il s'agit d'un risque de sécurité, à moins qu'une longueur de chiffrement suffisamment forte n'ait été utilisée" ?

J'apprécie les commentaires, mais tout le monde s'éloigne du sujet ici. Je ne protège pas Fort Knox. Je veux simplement conserver certains fichiers système pour mon serveur professionnel dans le nuage. Je pensais qu'il y aurait un moyen relativement facile et sécurisé (ou un service) pour faire cela en 2018. Merci encore.

Je m'excuse, mais votre question est littéralement "Y a-t-il un risque de sécurité à créer des clés publiques/privées à la racine et à ajouter la clé publique au repo GitHub ?"... Il semble que cela devrait vraiment être divisé en deux questions différentes. Pouvez-vous faire quelques modifications pour plus de clarté ?

@Rusty RSA 1024 cracké en quelques heures sur une seule machine en utilisant un GPU ? Je ne vous crois pas. Le défi RSA-768 a pris des mois sur plusieurs grands clusters. Tous les 4 bits supplémentaires du module doublent grossièrement le temps d'attaque. Ce dont vous avez été témoin était probablement une attaque sur des clés faibles générées avec trop peu d'aléatoire. Soit ça, soit vous venez de faire de vous une cible précieuse pour les agences de renseignement du monde entier.

@b0fh, tu m'as eu. Ils parlaient de l'avantage d'une réduction de l'entropie basée sur le moment (à la seconde près) et la manière dont les clés étaient générées sur une très vieille instance d'open ssh pour rendre faisable la quantité de travail nécessaire pour effectuer une attaque par force brute. Principalement pour faire un point sur la sécurité dans une salle de classe. Ce n'est peut-être pas une comparaison de pommes à pommes. Néanmoins, il faut une quantité de temps presque insignifiante pour générer une clé de 4096 bits, ce qui ne va pas faire de mal et rendrait toujours une attaque du même type et de la même ampleur infructueuse.