Cómo trabajar con GitHub si no está accesible directamente: proxychains, host de salto SSH y configuración de Git

En infraestructura real, el acceso a GitHub no siempre es directo. En algunos lugares bloquean el 22/tcp saliente, en otros HTTPS es inestable, hay DPI funcionando o la red corporativa permite la salida solo a través de un host intermedio (bastión). Aun así, el desarrollo y el despliegue no deben convertirse en una sesión de magia.

Analizaremos tres enfoques prácticos: desde un «parche» rápido con proxychains hasta un SSH Jump Host arquitectónicamente correcto.

Opción 1. Proxychains — cuando se necesita «aquí y ahora»

proxychains intercepta las llamadas de red de una aplicación y las envuelve en un proxy. Es útil para esquemas temporales o cuando hay que reenviar tráfico rápidamente a través de un SOCKS5 local (de sing-box, xray o un túnel SSH estándar).

Configuración

Instalamos (ejemplo en Debian/Ubuntu):

apt update && apt install -y proxychains4

Editamos /etc/proxychains4.conf. Al final del archivo añadimos los datos de nuestro proxy:

dynamic_chain
proxy_dns

[ProxyList]
# formato: tipo host puerto [usuario contraseña]
socks5 127.0.0.1 1080

Uso

Comprobamos la conexión:

proxychains4 ssh -T git@github.com

Si todo está bien, trabajamos con el repositorio simplemente añadiendo el prefijo:

proxychains4 git clone git@github.com:user/repo.git

Matiz: proxychains funciona en espacio de usuario mediante LD_PRELOAD. Esto puede no funcionar con binarios compilados estáticamente o en entornos específicos (por ejemplo, dentro de algunos contenedores).

Opción 2. SSH Jump Host — la vía «transparente» y correcta

Si tiene un VPS o un servidor bastión que pueda ver GitHub, es mejor usar las capacidades nativas de OpenSSH.

Variante básica (mediante alias)

Agregue a ~/.ssh/config:

Host jump-server
    HostName 1.2.3.4
    User admin
    Port 22

Host github-jump
    HostName github.com
    User git
    ProxyJump jump-server

Ahora el comando:

git clone git@github.com:user/repo.git

irá a través de su servidor.

Importante: En ese esquema su clave privada para GitHub permanece solo en su máquina. El jump-host actúa únicamente como retransmisor TCP.

Opción 3. Proxy nativo en Git (para HTTPS y SOCKS)

Si necesita trabajar a través del protocolo HTTPS o no quiere instalar proxychains, Git tiene configuraciones integradas.

Para SOCKS5

git config --global http.https://github.com.proxy socks5://127.0.0.1:1080

Para proxy HTTP con autenticación

git config --global http.proxy http://user:password@proxy.example.com:8080

Variables de entorno

Si necesita habilitar el proxy para un solo comando:

ALL_PROXY=socks5://127.0.0.1:1080 git pull

Depuración: si algo no funciona

1. Comprobación del apretón de manos SSH:

ssh -vvvT git@github.com

Observe en qué etapa se corta la conexión.

2. Comprobación de DNS:

En proxychains a menudo hay problemas con la resolución. Intente comentar proxy_dns si ve errores del tipo timeout.

3. Conectividad desde el jump host:

Conéctese al propio Jump Host y compruebe si ve GitHub:

nc -vz github.com 22

¿Qué elegir?

Proxychains: Si necesita «colar» tráfico rápidamente y ya tiene un cliente proxy local en funcionamiento.

SSH Jump Host: La opción más estable y segura para trabajo continuo. Ideal para servidores de despliegue y estaciones de trabajo.

Git Config: Si trabaja principalmente vía HTTPS o no quiere lidiar con configuraciones de SSH.