SSH vs HTTPS en Git: cómo dejar de introducir contraseñas y no perder las claves

¿Estás cansado de introducir contraseñas o tokens en cada git pull y git push?
¿Copias la llave SSH en cada servidor y temes que la roben o que “se quede” en los logs?
En este artículo veremos cuándo elegir SSH, cuándo HTTPS, cómo configurar el acceso a GitHub / GitLab de forma segura y cómo no convertir tu CI/CD en un cajón de tokens‑contraseñas.

La elección entre SSH y HTTPS no es cuestión de gusto, sino de seguridad y conveniencia para la automatización. Vamos a ver cómo configurar el acceso para que no entorpezca el trabajo.

1. SSH: Llaves y seguridad

SSH (Secure Shell) es el estándar para el trabajo continuo. En lugar de contraseñas se usan pares de llaves. Confirmas tu identidad poseyendo la llave privada, que nunca abandona tu equipo.

Cómo no repartir llaves (SSH Agent)

El principal error es copiar tu llave privada en cada servidor donde necesitas hacer git pull. Eso es un agujero de seguridad. En su lugar utiliza el reenvío de agente (Agent Forwarding).

La idea: Tu equipo local actúa como “guardián” de la llave. Cuando el servidor remoto quiere acceder a GitHub, reenvía la solicitud a tu agente local.

1. Agrega la llave al agente localmente

ssh-add ~/.ssh/id_ed25519

2. Permite el reenvío en ~/.ssh/config

En lugar de escribir ssh -A cada vez, configura la automatización para los hosts necesarios:

Host my-server
    HostName 1.2.3.4
    User admin
    ForwardAgent yes

Ahora, al conectarte a my-server, podrás clonar tus repositorios privados allí, pero la llave en sí no estará en el servidor.

2. Varias cuentas en un mismo dispositivo

Situación frecuente: GitLab del trabajo y GitHub personal. Usar una sola llave para todo es mala práctica. Para que Git elija automáticamente qué llave usar, utiliza alias en ~/.ssh/config.

2.1. Alias en ~/.ssh/config

Ejemplo de configuración:

# GitLab de trabajo
Host gitlab.work
    HostName gitlab.company.com
    IdentityFile ~/.ssh/id_ed25519_work

# GitHub personal
Host github.com
    HostName github.com
    IdentityFile ~/.ssh/id_ed25519_personal

Cómo usar esto:

• Al clonar un proyecto del trabajo utiliza el nombre de host del config:

  git clone git@gitlab.work:department/project.git
  

• Al trabajar con tu GitHub personal en las direcciones git remote quedará la estándar git@github.com:user/repo.git.

3. Cuando HTTPS es objetivamente mejor

No descartes HTTPS. Desde que GitHub pasó a Personal Access Tokens (PAT), este protocolo se volvió indispensable en ciertos casos.

3.1. Redes corporativas estrictas

Si los administradores de red han cerrado el puerto 22 (SSH), HTTPS por el puerto estándar 443 es tu salvación.

3.2. Docker y CI/CD

Dentro de contenedores Docker o pipelines temporales es más sencillo pasar un token mediante una variable de entorno que lidiar con la generación y el registro de llaves SSH.

3.3. Tareas puntuales

Si necesitas descargar código rápidamente en un equipo ajeno, es más fácil generar un token temporal en el navegador que dejar rastros en forma de llaves.

3.4. Peligros de https://<TOKEN>@... y alternativas seguras

Usar el token directamente en la URL:

git clone https://<TOKEN>@github.com/username/repo.git

— es una práctica extremadamente insegura: el token puede terminar en:

• el historial del shell (~/.bash_history);
• logs de CI/CD;
• capturas de pantalla y notas.

Mejor así:

• usa git config con credential.helper:

  git config credential.helper store
  # luego, al primer pedido, ingresa usuario/token
  

• o pasa el token mediante variables de entorno en CI/CD (GitHub Actions, GitLab CI, etc.).

4. Comparación SSH vs HTTPS

Conclusión de la tabla:

• Para tu máquina personal y servidores de confianza — SSH con agente y ~/.ssh/config.
• Para CI/CD, builds Docker, redes restringidas y tareas puntuales — HTTPS con tokens, pero sin tokens en la URL.

5. Cómo cambiar de protocolo en un proyecto existente

Si clonaste el proyecto por HTTPS y quieres pasar a SSH (o al revés), no hace falta borrar la carpeta y re-clonar. Simplemente cambia la URL del repositorio remoto.

Cambiar a SSH

git remote set-url origin git@github.com:user/repo.git

Cambiar a HTTPS

git remote set-url origin https://github.com/user/repo.git

Después de eso, todos los siguientes git pull / git push usarán el nuevo protocolo.

Conclusión

Para tu máquina y servidores de confianza elige SSH con agente configurado y ~/.ssh/config: es seguro, cómodo y escalable.
Deja HTTPS para:

• pipelines CI/CD;
• builds Docker;
• condiciones de red restringidas;
• tareas puntuales.

Una combinación adecuada de estos enfoques es una práctica DevOps madura.

Lista de verificación práctica: cómo configurar

1. Generar llaves SSH:

   ssh-keygen -t ed25519 -C "your_email@example.com"
   

2. Agregar la llave al agente SSH:

   ssh-add ~/.ssh/id_ed25519
   

3. Configurar ~/.ssh/config para varias cuentas:

   Host gitlab.work
       HostName gitlab.company.com
       IdentityFile ~/.ssh/id_ed25519_work
   
   Host github.com
       HostName github.com
       IdentityFile ~/.ssh/id_ed25519_personal
   

4. Verificar el acceso:

   ssh -T git@gitlab.work
   ssh -T git@github.com
   

5. En CI/CD usar HTTPS con tokens mediante variables de entorno, sin incluirlos en la URL.