Sur le site GitHub il y a un lien ...

https://help.github.com/articles/generating-ssh-keys

... et ça dit ...

Si vous avez décidé de ne pas utiliser la méthode HTTPS recommandée, nous pouvons utiliser des clés SSH pour établir une connexion sécurisée entre votre ordinateur et GitHub. Les étapes ci-dessous vous guideront à travers la génération d'une clé SSH, puis l'ajout de la clé publique à votre compte GitHub.

Pourquoi HTTPS est-il la méthode recommandée? Existe-t-il une sorte de faille de sécurité dans la méthode SSH ou est-ce plus lent? J'ai créé une clé SSH, cela atténuerait-il les problèmes de sécurité?

GitHub a changé sa recommandation plusieurs fois ( exemple ).

Il semble qu'ils recommandent actuellement HTTPS car il est le plus facile à installer sur la plus large gamme de réseaux et de plates-formes, et par des utilisateurs qui sont nouveaux dans tout cela.

Il n'y a pas de faille inhérente à SSH (s'ils l'étaient, ils le désactiveraient) - dans les liens ci-dessous, vous verrez qu'ils fournissent également des détails sur les connexions SSH:

1. HTTPS est moins susceptible d'être bloqué par un pare-feu.

   https://help.github.com/articles/which-remote-url-should-i-use/

   Les URL https: // clone sont disponibles sur tous les référentiels, publics et privés. Ces URL fonctionnent partout - même si vous êtes derrière un pare-feu ou un proxy.

2. Une connexion HTTPS permet credential.helperde mettre en cache votre mot de passe.

   https://help.github.com/articles/set-up-git

   Bon à savoir: l'assistant d'informations d'identification ne fonctionne que lorsque vous clonez une URL de dépôt HTTPS. Si vous utilisez l'URL de dépôt SSH à la place, les clés SSH sont utilisées pour l'authentification. Bien que nous ne le recommandions pas, si vous souhaitez utiliser cette méthode, consultez ce guide pour vous aider à générer et à utiliser une clé SSH.

Je suppose que HTTPS est recommandé par GitHub pour plusieurs raisons

1) Il est plus simple à utiliser de n'importe où car vous n'avez besoin que des détails de votre compte (aucune clé SSH requise)

2) HTTPS Est un port ouvert dans tous les pare-feu. SSH n'est pas toujours ouvert comme port de communication avec les réseaux externes

Un référentiel GitHub est donc plus universellement accessible via HTTPS que SSH.

À mon avis, les clés SSH valent le peu de travail supplémentaire pour les créer

1) Les clés SSH ne donnent pas accès à votre compte GitHub, donc votre compte ne peut pas être détourné si votre clé est volée,

2) L'utilisation d'une phrase clé forte avec votre clé SSH limite toute utilisation abusive, même si votre clé est volée

Si vos informations d'identification de compte GitHub (nom d'utilisateur / mot de passe) sont volées, votre mot de passe GitHub peut être modifié pour vous bloquer l'accès et tous vos référentiels partagés peuvent être rapidement supprimés.

Si une clé privée est volée, quelqu'un peut effectuer une poussée forcée d'un référentiel vide et effacer tout l'historique des modifications pour chaque référentiel que vous possédez, mais ne peut rien changer dans votre compte GitHub. Il sera beaucoup plus facile d'essayer de récupérer de cette violation si vous avez accès à votre compte GitHub.

Ma préférence est d'utiliser SSH avec une clé protégée par mot de passe. J'ai une clé SSH différente pour chaque ordinateur, donc si cette machine est volée ou compromise, je peux rapidement me connecter à GitHub et supprimer cette clé pour empêcher tout accès indésirable.

SSH peut être tunnelé via HTTPS si le réseau sur lequel vous vous trouvez bloque le port SSH.

https://help.github.com/articles/using-ssh-over-the-https-port/

Si vous utilisez HTTPS, je recommanderais d'ajouter une authentification à deux facteurs, pour protéger votre compte ainsi que vos référentiels.

Si vous utilisez HTTPS avec un outil (par exemple un éditeur), vous devez utiliser un jeton de développeur de votre compte GitHub plutôt que de mettre en cache le nom d'utilisateur et le mot de passe dans cette configuration d'outils.

Soit vous citez mal, soit github a des recommandations différentes sur différentes pages, soit ils peuvent apprendre avec le temps et mettre à jour leur reco.

Nous vous recommandons fortement d'utiliser une connexion SSH lors de l'interaction avec GitHub. Les clés SSH sont un moyen d'identifier les ordinateurs de confiance, sans impliquer de mots de passe. Les étapes ci-dessous vous guideront à travers la génération d'une clé SSH, puis l'ajout de la clé publique à votre compte GitHub.

https://help.github.com/articles/generating-ssh-keys

Activation des connexions SSH sur HTTPS s'il est bloqué par le pare-feu

Testez si SSH sur le port HTTPS est possible, exécutez cette commande SSH:

$ ssh -T -p 443 git@ssh.github.com
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

Si cela a fonctionné, tant mieux! Sinon, vous devrez peut-être suivre notre guide de dépannage .

Si vous pouvez SSH git@ssh.github.comsur le port 443 , vous pouvez remplacer vos paramètres SSH pour forcer toute connexion à GitHub à s'exécuter via ce serveur et ce port.

Pour définir cela dans votre configuration ssh, modifiez le fichier à ~/.ssh/configet ajoutez cette section:

Host github.com
  Hostname ssh.github.com
  Port 443

Vous pouvez tester que cela fonctionne en vous connectant à nouveau à GitHub:

$ ssh -T git@github.com
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

De l' authentification à GitHub / Utilisation de SSH sur le port HTTPS

Voir aussi: l' URL officielle à distance que dois-je utiliser? répondez sur help.github.com.

ÉDITER:

Il semble qu'il ne soit plus nécessaire d'avoir un accès en écriture à un référentiel public pour utiliser une URL SSH, ce qui rend invalide mon explication d'origine.

ORIGINAL:

Apparemment, la principale raison de favoriser les URL HTTPS est que les URL SSH ne fonctionneront pas avec un référentiel public si vous n'avez pas accès en écriture à ce référentiel.

L'utilisation d'URL SSH est encouragée pour le déploiement sur des serveurs de production, cependant - le contexte ici est probablement des services comme Heroku.

Il est possible d'affirmer que l'utilisation de la clé SSH pour l'authentification est moins sécurisée car nous avons tendance à changer notre mot de passe plus périodiquement que nous ne générons de nouvelles clés SSH.

Les serveurs qui limitent la durée de vie pour laquelle ils honoreront les clés SSH données peuvent aider à forcer les utilisateurs à pratiquer la régénération périodique des clés SSH.

Peut-être parce qu'il est plus difficile de voler un mot de passe de votre cerveau que de voler un fichier clé de votre ordinateur (au moins à ma connaissance, peut-être que certaines substances existent déjà ou des méthodes mais c'est une discussion infinie)? Et si vous protégez la clé par mot de passe, vous utilisez à nouveau un mot de passe et les mêmes problèmes se posent (mais certains pourraient faire valoir que vous devez faire plus de travail, car vous devez obtenir la clé, puis casser le mot de passe).