Understanding ssh Agent Forwarding
SSH login works.
git pull doesn’t.
You connect to a server:
ssh root@server
No password. All good.
Then:
git pull origin main
Boom:
Permission denied (publickey)
You check:
ssh-add -L
And get:
Could not open a connection to your authentication agent.
At this point, it feels wrong.
“I logged in using SSH keys… why is Git failing?”
The trap
Logging in via SSH does not mean the server has your keys.
It only means:
- your local machine proved its identity
- the server said “okay, you’re allowed in”
That’s it.
Your private key never leaves your machine.
What changes after login
Once you’re inside:
- you are now
root(or some user) - the system looks for keys in:
/root/.ssh/
And in your case:
(empty)
So when Git tries to talk to GitHub/GitLab:
- it looks for a key
- finds nothing
- fails
That ssh-add error
Could not open a connection to your authentication agent.
This just means:
there is no SSH agent running here
Even if you start one, it still won’t have your keys.
The fix (don’t copy keys)
Use agent forwarding.
From your local machine:
ssh -A root@server
Now on the server:
ssh-add -L
You’ll see your key.
Then:
git pull
Works.
What actually happened
ssh -A creates a tunnel back to your local SSH agent.
So when the server needs to authenticate:
- it asks your local machine
- your local machine signs the request
- the key never leaves your laptop
Make it default
Instead of remembering -A every time:
~/.ssh/config
Host my-server
HostName your.server.com
User root
ForwardAgent yes
Now:
ssh my-server
Done.
When to use this
- personal servers → yes
- quick debugging → yes
- production / shared machines → be careful
Because:
the server can use your identity while you’re connected
Alternative
If you don’t like forwarding:
- generate a key on the server
- add it to GitHub/GitLab
Now the server has its own identity.
Mental model
- SSH login works → you are trusted
- Git fails → server is not trusted
ssh -A→ lets server borrow your identity
That’s all this is.
Simple once you see it.