¿Por qué GitHub recomienda HTTPS sobre SSH?


334

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?


39
Menos configuración significa más fácil, tal vez. Además, algunos sistemas operativos inferiores ni siquiera tienen clientes SSH instalados por defecto.
katspaugh

45
Para los futuros usuarios que encuentren este hilo: GitHub ha cambiado su política y ahora dice "Recomendamos encarecidamente utilizar una conexión SSH al interactuar con GitHub".
beardedlinuxgeek

99
@StevePomeroy, no creo que exista la declaración de "recomendar encarecidamente" en esa ubicación.
Noel Abrahams

55
@BonsaiOak Solía ​​estar en la página vinculada a Steve Pomeroy: web.archive.org/web/20140321204642/https://help.github.com/… , pero parece que lo han cambiado desde entonces.
beardedlinuxgeek

55
@ Br3nt Derecha. Solían no recomendarlo. Entonces lo hicieron. Entonces no lo hicieron otra vez. Es por eso que mi enlace es a una página archive.org
beardedlinuxgeek

Respuestas:


192

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.


52
Ah, ¿entonces recomiendan HTTPS simplemente para que no tengan que documentar ssh-agent? Lo suficientemente justo. ¡Gracias!
sarnold

74
@sarnold Probablemente tenga más que ver con el volumen de preguntas relacionadas con la administración de claves públicas y ssh-agent, y la cantidad de firewalls corporativos que permiten HTTP / HTTPS salientes pero no SSH.
Todd A. Jacobs

77
Creo que https facilita el inicio de las personas, ya que no tiene que hacer todo el negocio de generar / copiar / pegar claves ssh. También podría verse como más seguro desde la perspectiva de Github, ya que un atacante que obtuvo su contraseña ssh (o encontró un terminal de computadora que dejó abierto) aún tendría que conocer su contraseña de Github para empujar cualquier cosa.
k107

44
@kristi Si el atacante encuentra esa terminal antes de que caduque el caché de contraseñas, ¿no podría seguir presionando aunque no conozca la contraseña? La pregunta es casi la misma si usa ssh-agent, la diferencia obvia es que debe ingresar la contraseña de la clave ssh en lugar de su contraseña de github (y parece que no hay una configuración obvia para la caducidad de la memoria caché). La idea de ingresar la contraseña de github en lugar de la contraseña de la clave ssh parece un paso atrás, aunque pequeña, ya que el poder que le dan las dos teclas es casi el mismo AFAIK.
Halil Özgür

8
Creo que se trata casi por completo de reducir el volumen de consultas de soporte que reciben. Supongo que también se podría argumentar que, dado que tiene que introducir su contraseña a través de HTTPS todos modos para acceder a la página web, no se puede ser el aumento de la seguridad mediante el uso de un mecanismo de autenticación diferente (claves SSH), pero es factible que está aumentando la superficie de ataque que podría disminuir la seguridad. Aún así, tanto HTTPS como SSH deben ser adecuadamente seguros si se usan correctamente.
Cartroo

52

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.


3
"aunque si alguien obtiene su clave privada, puede forzar un depósito vacío y borrar su historial de cambios" - sí (y sería horrible), pero la belleza de las bases de código distribuidas nos permite recuperarnos con alguien que tiene una copia al menos.
Cameron

No estoy seguro de afirmar que alguien que pueda forzar el empuje sea un diferenciador entre SSH y HTTPS. Si tuviera su nombre de usuario y contraseña, igualmente podría forzar la inserción.
Matt Canty

Si tiene nombre de usuario y contraseña, puede eliminar todo (después de cambiar la contraseña y el contacto de correo electrónico, por supuesto). No es necesario hacer un empuje forzado individual en cada repositorio si solo puede eliminarlos.
jr0cket

está comparando la contraseña con la clave ssh, mientras que la conexión https requiere un token especial.
Alexey Sh.

13

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


22
FWIW, esta página ya no contiene el texto "muy recomendable" citado en esta respuesta.
Scott Isaacs

El uso todavía "recomendado" para HTTPS en el siguiente enlace: help.github.com/articles/which-remote-url-should-i-use/… "Clonación con URL HTTPS (recomendado)"
JBE

10

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 git@ssh.github.com
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 git@ssh.github.comtravé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 git@github.com
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


9

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.


1
"Estas URL proporcionan acceso a un repositorio git a través de SSH. Para usar estas URL, debe tener acceso de escritura a un repositorio público o cualquier acceso a un repositorio privado. Estas URL no funcionarán con un repositorio público al que no tiene acceso de escritura " - ESTO NO ES VERDAD. Cualquiera puede clonar un repositorio público con una URL SSH a la que no tienen acceso de escritura
Sam

1
@Sam Puede que ya no sea cierto, pero era cierto cuando respondí la pregunta. He editado mi respuesta para reflejar el cambio.
Mark Tye

En efecto. La pregunta "¿Cómo recomienda GitHub HTTPS sobre SSH" no tendría sentido?
Mark Tye

0

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.


Ahora se considera un mal consejo hacer que los usuarios cambien sus contraseñas periódicamente. Opinión de los gobiernos del Reino Unido: ncsc.gov.uk/articles/problems-forcing-regular-password-expiry
nazerb

-3

¿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).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.