How to work with GitHub when it's not directly accessible: proxychains, SSH Jump Host and Git Config

In real infrastructure, access to GitHub is not always direct. Somewhere outgoing 22/tcp is blocked, somewhere HTTPS is unstable, DPI is in place, or the corporate network allows outbound only through an intermediate host (bastion). Development and deploy should not turn into a magic session.

Let’s look at three working approaches: from a quick “hack” with proxychains to the architecturally correct SSH Jump Host.

Option 1. Proxychains — when you need “here and now”

proxychains intercepts an application’s network calls and wraps them through a proxy. This is convenient for temporary schemes or when you need to quickly route traffic through a local SOCKS5 (from sing-box, xray, or a regular SSH tunnel).

Setup

Install (example for Debian/Ubuntu):

apt update && apt install -y proxychains4

Edit /etc/proxychains4.conf. Add your proxy details to the end of the file:

dynamic_chain
proxy_dns

[ProxyList]
# формат: тип host port [user pass]
socks5 127.0.0.1 1080

(Translate the comment inside code: “# format: type host port [user pass]”)

Usage

Check the connection:

proxychains4 ssh -T git@github.com

If everything is OK, work with the repository by simply adding the prefix:

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

Nuance: proxychains works in user-space via LD_PRELOAD. This may not work with statically compiled binaries or in specific environments (for example, inside some containers).

Option 2. SSH Jump Host — the “transparent” and correct way

If you have a VPS or a bastion server that can see GitHub, it’s better to use the native capabilities of OpenSSH.

Basic variant (via alias)

Add to ~/.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

Now the command:

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

will go through your server.

Important: With this scheme your private key for GitHub remains only on your machine. The jump host acts only as a TCP relay.

Option 3. Native proxy in Git (for HTTPS and SOCKS)

If you need to work over HTTPS or you don’t want to install proxychains, Git has built-in settings.

For SOCKS5

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

For HTTP proxy with authentication

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

Environment variables

If you need to enable a proxy for a single command:

ALL_PROXY=socks5://127.0.0.1:1080 git pull

Troubleshooting: if something doesn’t work

1. Check the SSH handshake:

ssh -vvvT git@github.com

See at which stage the connection is dropped.

2. Check DNS:

With proxychains there are often issues with resolution. Try commenting out proxy_dns if you see errors like timeout.

3. Connectivity from the jump host:

Log in to the Jump Host itself and check whether it can see GitHub:

nc -vz github.com 22

What to choose?

Proxychains: If you need to quickly push traffic through and you already have a local proxy client running.

SSH Jump Host: The most stable and secure option for permanent work. Ideal for deployment servers and workstations.

Git Config: If you mostly work over HTTPS or don’t want to fiddle with SSH configs.