¿git clone con HTTPS o SSH remoto?
git clone admite URL remotas HTTPS y SSH. ¿Cuál debo usar? ¿Cuáles son las ventajas de cada uno?
Los documentos de GitHub no hacen recomendaciones de ninguna manera. Recuerdo que en 2013 GitHub solía recomendar SSH (enlace de archivo). ¿Por qué fue eso?
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 por usuarios nuevos en todo esto.
No hay ningún defecto inherente en SSH (si lo hubiera, lo desactivarían). En los enlaces siguientes, verá que también proporcionan detalles sobre las conexiones SSH:
Es menos probable que HTTPS sea bloqueado por un firewall.
https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls
Las
https://URL clonadas están disponibles en todos los repositorios, independientemente de su visibilidad.https://Las URL clonadas funcionan incluso si estás detrás de un firewall o proxy.Una conexión HTTPS permite
credential.helperalmacenar en caché su contraseña.https://docs.github.com/en/get-started/quickstart/set-up-git#connecting-over-https-recommended
Si clona con HTTPS, puede almacenar en caché sus credenciales de GitHub en Git utilizando un asistente de credenciales. Para obtener más información, consulte " Clonación con URL HTTPS " y " Almacenamiento en caché de sus credenciales de GitHub en Git " .
Supongo que GitHub recomienda HTTPS por varias razones
Es más sencillo acceder a un repositorio desde cualquier lugar, ya que solo necesita los detalles de su cuenta (no se requieren claves SSH) para escribir en el repositorio.
HTTPS Es un puerto que está abierto en todos los firewalls. SSH no siempre está abierto como puerto para la comunicación con redes externas
Por lo tanto, un repositorio de GitHub es más accesible universalmente utilizando HTTPS que SSH.
En mi opinión, las claves SSH merecen el pequeño trabajo extra para crearlas.
Las claves SSH no brindan acceso a su cuenta de GitHub, por lo que su cuenta no puede ser secuestrada si le roban la clave.
El uso de una frase clave segura con su clave SSH limita cualquier uso indebido, incluso si le roban la clave (después de romper primero la protección de acceso a su cuenta de computadora)
Si le roban las credenciales de su cuenta de GitHub (nombre de usuario/contraseña), su contraseña de GitHub se puede cambiar para bloquearle el acceso y todos sus repositorios compartidos se pueden eliminar rápidamente.
Si se roba una clave privada, alguien puede forzar el envío de un repositorio vacío y borrar todo el historial de cambios de cada repositorio de su propiedad, pero no puede cambiar nada en su cuenta de GitHub. Será mucho más fácil intentar recuperarse de esta infracción si tiene acceso a su cuenta de GitHub.
Mi preferencia es utilizar SSH con una clave protegida con contraseña. Tengo una clave SSH diferente para cada computadora, por lo 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, le 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 de almacenar en caché el nombre de usuario y la contraseña en la configuración de esa herramienta. Un token mitigaría parte del riesgo potencial de usar HTTPS, ya que los tokens se pueden configurar para privilegios de acceso muy específicos y se pueden revocar fácilmente si ese token se ve comprometido.
O estás citando mal o github tiene recomendaciones diferentes 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
Recomendación : use HTTPS con un asistente de credenciales OAuth como Git Credential Manager o git-credential-oauth .
¡No más contraseñas ni tokens de acceso personal! La primera vez que presione, el asistente abrirá una ventana del navegador para autenticarse. Los envíos posteriores dentro de la vida útil del almacenamiento no requieren interacción.
Desventajas de SSH:
- Se autentica innecesariamente al clonar o recuperar un repositorio público.
- Es necesario instalar el cliente SSH.
- La creación de una clave SSH no es familiar para muchos usuarios nuevos de Git.
- Para protegerse contra ataques de intermediario, el usuario debe verificar manualmente las huellas digitales del host . ¡No todo el mundo se molesta!
- Configurar una clave con un host implica copiar y pegar entre la terminal y un sitio web. Para utilizar 3 computadoras con 5 hosts, el usuario debe hacerlo 15 veces.
- Las claves SSH sin frase de contraseña se almacenan en texto sin formato sin caducidad.
- La frase de contraseña de la clave SSH (si se utiliza) debe escribirse periódicamente. Incluso después de configurar ssh-agent, se debe escribir la frase de contraseña después de cada reinicio del sistema.
- A veces, los cortafuegos bloquean SSH.
Ventajas de HTTPS:
- Sin autenticación para clonar o recuperar un repositorio público.
- La autenticidad del servidor se verifica automáticamente mediante un certificado HTTPS.
- Suponiendo que utiliza un asistente de credenciales OAuth como Git Credential Manager o git-credential-oauth , nunca tendrá que escribir una contraseña ni configurar un token de acceso personal.
- El protocolo OAuth protege contra el robo de tokens mediante el uso de tokens de corta duración y una rotación de tokens de actualización que detecta ataques de repetición. Esta es una ventaja sobre los tokens de acceso personal.
- Las credenciales se pueden almacenar en caché o en un almacenamiento específico de la plataforma, como wincred, osxkeychain o libsecret.
