Stop Using HTTPS for Git — Switch to SSH Before AI Agents Leak Your Credentials

"Your git pull is going to break."

I stored business documents — PDFs, images, spreadsheets, about 110 files totaling 35MB — in a private GitHub repo. The plan was simple: version-control everything, let AI agents access it from any machine.

Then I ran git pull from a second PC:

error: RPC failed; curl 56 GnuTLS recv error (-54)
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

Clone didn't work either. My repository was unreachable. The cause? HTTPS and its dependency on GnuTLS.

Why HTTPS Breaks Under Load

When you run git clone https://..., here's the stack:

git clone (HTTPS)
  └→ git-remote-https
       └→ libcurl (HTTP library)
            └→ libgnutls (SSL/TLS)  ← breaks here
                 └→ TCP → GitHub

Ubuntu's default Git uses GnuTLS for HTTPS. GnuTLS has known issues with large transfers — a combination of buffer size limits, version-specific bugs, and MTU mismatches (especially on WSL2) can cause the TLS connection to drop mid-transfer.

You can verify your Git uses GnuTLS:

ldd /usr/lib/git-core/git-remote-https | grep tls
# libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30

There are workarounds: increase http.postBuffer, upgrade GnuTLS, or recompile Git with OpenSSL. But these are band-aids on a deeper problem. Even if you fix the transfer issue, HTTPS still has an authentication problem that matters more in the age of AI agents.

The HTTPS Authentication Problem

Beyond the GnuTLS issue, HTTPS has a credential management problem:

With AI agents running on your machine, every one of these is an attack surface. An agent that can execute shell commands can read .git-credentials, shell history, or environment variables.

Why SSH Is Different

SSH uses public-key cryptography. Your private key never leaves your machine, and the authentication doesn't involve tokens or passwords in transit.

git clone (SSH)
  └→ ssh (OpenSSH client)
       └→ libcrypto (OpenSSL)  ← battle-tested
            └→ TCP → GitHub

The critical difference:

Setup: 5-Minute SSH Migration

1. Generate a key

ssh-keygen -t ed25519 -C "[email protected]"
# Accept default path, set a passphrase

2. Add to ssh-agent

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

3. Register on GitHub

cat ~/.ssh/id_ed25519.pub
# Copy the output → GitHub → Settings → SSH Keys → New

4. Switch existing repos

git remote set-url origin [email protected]:USER/REPO.git

5. Verify

ssh -T [email protected]
# "Hi USER! You've successfully authenticated"

WSL2 Users: One Extra Step

If you're on WSL2, the SSH agent doesn't persist across sessions. Add this to your ~/.bashrc:

if [ -z "$SSH_AUTH_SOCK" ]; then
    eval "$(ssh-agent -s)" > /dev/null 2>&1
    ssh-add ~/.ssh/id_ed25519 2>/dev/null
fi

The AI Agent Angle

This isn't just about convenience. When AI agents like Claude Code or Cursor manage your repos, they execute git commands on your behalf. With HTTPS:

• The agent needs access to your token
• The token is in an environment variable or credential file
• A prompt injection attack can read that token

With SSH (passphrase + ssh-agent):

• The agent uses the ssh-agent socket
• The private key file exists on disk, but is encrypted with your passphrase
• A compromised agent could attempt cat ~/.ssh/id_ed25519, but gets an encrypted blob — not a usable key
• The agent can use the key through the socket for the current session, but can't extract it

Important: this only works if you set a passphrase during ssh-keygen. Without a passphrase, the private key is readable plaintext. SSH without a passphrase is better than HTTPS tokens, but not by as much as you'd think.

SSH doesn't make you invulnerable, but it reduces the blast radius significantly.

If you're building AI-native workflows and want to understand the full security picture — from CLAUDE.md defense to credential isolation — I cover the patterns in my book:

📖 Practical Claude Code: Context Engineering for Modern Development