En el sitio de GitHub hay un enlace ...

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

... y dice ...

Si ha decidido no usar el método HTTPS recomendado, podemos usar las claves SSH para establecer una conexión segura entre su computadora y GitHub. Los pasos a continuación lo guiarán para generar una clave SSH y luego agregar la clave pública a su cuenta de GitHub.

¿Por qué HTTPS es el método recomendado? ¿Hay algún tipo de falla de seguridad en el método SSH o es más lento? Creé una clave SSH, ¿eso mitigaría cualquier problema de seguridad?

GitHub ha cambiado su recomendación varias veces ( ejemplo ).

Parece que actualmente recomiendan HTTPS porque es el más fácil de configurar en la más amplia gama de redes y plataformas, y para los usuarios que son nuevos en todo esto.

No hay ningún defecto inherente en SSH (si hubiera, lo deshabilitarían): en los enlaces a continuación, verá que también proporcionan detalles sobre las conexiones SSH:

1. HTTPS tiene menos probabilidades de ser bloqueado por un firewall.

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

   Las URL de clonación https: // están disponibles en todos los repositorios, públicos y privados. Estas URL funcionan en todas partes, incluso si está detrás de un firewall o proxy.

2. Una conexión HTTPS le permite credential.helperalmacenar en caché su contraseña.

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

   Es bueno saberlo: el asistente de credenciales solo funciona cuando clonas una URL de repositorio HTTPS. Si utiliza la URL de repositorio SSH, las claves SSH se utilizan para la autenticación. Si bien no lo recomendamos, si desea utilizar este método, consulte esta guía para obtener ayuda para generar y usar una clave SSH.

Supongo que GitHub recomienda HTTPS por varias razones

1) Es más fácil de usar desde cualquier lugar ya que solo necesita los detalles de su cuenta (no se requieren claves SSH)

2) HTTPS es un puerto que está abierto en todos los firewalls. SSH no siempre está abierto como puerto para la comunicación a redes externas

Por lo tanto, un repositorio de GitHub es más universalmente accesible usando HTTPS que SSH.

En mi opinión, las claves SSH valen el poco trabajo extra para crearlas.

1) Las claves SSH no proporcionan acceso a su cuenta de GitHub, por lo que su cuenta no puede ser secuestrada si le roban su clave,

2) El uso de una frase clave fuerte con su clave SSH limita el uso indebido, incluso si su clave es robada

Si le roban las credenciales de su cuenta de GitHub (nombre de usuario / contraseña), su contraseña de GitHub se puede cambiar para bloquear el acceso y todos sus repositorios compartidos se pueden eliminar rápidamente.

Si se roba una clave privada, alguien puede presionar forzosamente un repositorio vacío y borrar todo el historial de cambios para cada repositorio que posea, pero no puede cambiar nada en su cuenta de GitHub. Será mucho más fácil intentar la recuperación de esta infracción en la que tiene acceso a su cuenta de GitHub.

Mi preferencia es usar SSH con una clave protegida con frase de contraseña. Tengo una clave SSH diferente para cada computadora, así que si esa máquina es robada o la clave se ve comprometida, puedo iniciar sesión rápidamente en GitHub y eliminar esa clave para evitar el acceso no deseado.

SSH se puede tunelizar a través de HTTPS si la red en la que se encuentra bloquea el puerto SSH.

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

Si usa HTTPS, recomendaría agregar autenticación de dos factores para proteger su cuenta y sus repositorios.

Si usa HTTPS con una herramienta (por ejemplo, un editor), debe usar un token de desarrollador de su cuenta de GitHub en lugar del nombre de usuario y contraseña de la memoria caché en esa configuración de herramientas.

O estás citando mal o github tiene diferentes recomendaciones en diferentes páginas o pueden aprender con el tiempo y actualizar su reco.

Recomendamos encarecidamente utilizar una conexión SSH al interactuar con GitHub. Las claves SSH son una forma de identificar computadoras confiables, sin involucrar contraseñas. Los pasos a continuación lo guiarán para generar una clave SSH y luego agregar la clave pública a su cuenta de GitHub.

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

Habilitar conexiones SSH a través de HTTPS si está bloqueado por el firewall

Pruebe si es posible SSH sobre el puerto HTTPS, ejecute este comando SSH:

$ ssh -T -p 443 [email protected]
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

Si eso funcionó, ¡genial! De lo contrario, es posible que deba seguir nuestra guía de solución de problemas .

Si puede ingresar SSH a [email protected]través del puerto 443 , puede anular la configuración de SSH para forzar la ejecución de cualquier conexión a GitHub a través de ese servidor y puerto.

Para configurar esto en su configuración ssh, edite el archivo en ~/.ssh/configy agregue esta sección:

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

Puede probar que esto funciona conectándose una vez más a GitHub:

$ ssh -T [email protected]
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

Desde la autenticación hasta GitHub / Uso de SSH sobre el puerto HTTPS

Ver también: el oficial ¿Qué URL remota debo usar? responda en help.github.com.

EDITAR:

Parece que ya no es necesario tener acceso de escritura a un repositorio público para usar una URL SSH, lo que invalida mi explicación original.

ORIGINAL:

Aparentemente, la razón principal para favorecer las URL HTTPS es que las URL SSH no funcionarán con un repositorio público si no tiene acceso de escritura a ese repositorio.

Sin embargo, se recomienda el uso de URL SSH para la implementación en servidores de producción; presumiblemente, el contexto aquí es servicios como Heroku.

Es posible argumentar que usar la clave SSH para autenticarse es menos seguro porque tendemos a cambiar nuestra contraseña más periódicamente de lo que generamos nuevas claves SSH.

Los servidores que limitan la vida útil por la cual honrarán las claves SSH dadas pueden ayudar a obligar a los usuarios a la práctica de actualizar periódicamente las claves SSH.

¿Tal vez porque es más difícil robar una contraseña de su cerebro que robar un archivo de clave de su computadora (al menos que yo sepa, tal vez ya existan algunas sustancias o métodos, pero esta es una discusión infinita)? Y si protege la clave con una contraseña, entonces está usando una contraseña nuevamente y surgen los mismos problemas (pero algunos podrían argumentar que debe hacer más trabajo, porque necesita obtener la clave y luego descifrar la contraseña).