Git SSH "kex_exchange_identification: Connection closed" in CI

By Kaveh Alemi·Latchkey

The remote closed the SSH connection before key exchange even began. This is a transport-level cutoff - a blocked or proxied port 22, a transient rate limit, or a network interruption - not a key or permissions problem.

What this error means

An SSH clone/fetch fails with kex_exchange_identification: Connection closed by remote host and fatal: Could not read from remote repository. It can be intermittent (succeeds on retry) or consistent when port 22 is blocked.

kex_exchange_identification: Connection closed by remote host
Connection closed by 140.82.x.x port 22
fatal: Could not read from remote repository.

Diagnose it: depth, refs, or credentials?

git rev-parse --is-shallow-repository
git rev-parse --abbrev-ref HEAD    # prints HEAD when detached
git log --oneline -3
git remote -v

Common causes

Port 22 blocked or proxied

A firewall or network that does not allow outbound SSH on port 22 closes the connection before the handshake completes.

Transient rate limit or network blip

The host may briefly drop connections under load or rate limiting, so the same command succeeds on a retry.

How to fix it

Use SSH over the HTTPS port (443)

GitHub serves SSH on port 443 via ssh.github.com, which bypasses a blocked port 22.

cat >> ~/.ssh/config <<'EOF'
Host github.com
  Hostname ssh.github.com
  Port 443
EOF
ssh -T git@github.com

Retry the transient failure

When the cutoff is intermittent, a bounded retry around the clone clears most blips.

for i in 1 2 3; do
  git clone git@github.com:org/repo.git && break
  echo "ssh clone failed (attempt $i), retrying..."; sleep 5
done

How to prevent it

• Allow outbound SSH (port 22), or use ssh.github.com:443 on locked-down networks.
• Wrap SSH clones in a bounded retry to absorb transient cutoffs.
• Fall back to the HTTPS remote where SSH egress is not permitted.

Frequently asked questions

Related guides

References

• Git reference manual
• GitHub Actions documentation