Disable SSH agent and X11 forwarding

The fix/etc/ssh/sshd_config

AllowAgentForwarding no
X11Forwarding no

Then reload the daemon:

sudo systemctl reload ssh     # Debian, Ubuntu
sudo systemctl reload sshd    # RHEL, Rocky, Alma, Fedora

Why it matters

Agent forwarding is the one that bites. When you connect with ssh -A, your local SSH agent is exposed to the remote host through a socket. Anyone who can read that socket — which includes root on that host, and any process running as your user — can ask your agent to sign authentication challenges. They cannot steal the key itself, but they don’t need to: for as long as your session is open, they can authenticate as you to any host your key opens.

So a single compromised server turns into every server you can reach from it. That is a lateral-movement path created entirely by a convenience feature.

X11 forwarding matters less on a server, mostly because servers rarely run X clients — but an untrusted remote X client can interact with your local display, including reading keystrokes. If nothing on the host needs a GUI, there’s no reason to leave it on.

Use ProxyJump instead

Agent forwarding usually exists to solve “I need to reach host B, and only host A can see it.” ProxyJump solves that properly: the authentication happens on your machine, and the jump host only ever relays an encrypted stream. Your agent is never exposed to it.

ssh -J bastion.example.com internal-host

Or make it permanent, client-side:

~/.ssh/config

Host internal-host
  ProxyJump bastion.example.com

This is strictly better than -A, and it is why agent forwarding can usually be turned off with nothing lost.

What about AllowTcpForwarding?

AllowTcpForwarding no is often bundled into hardening lists. Be careful: it breaks port forwarding and tunnels, which is exactly what ProxyJump and database tunnels rely on. Turn it off only if you know nothing depends on it — it is not a free win, and disabling it on a bastion defeats the bastion.

Verify it worked

Check the running daemon:

sudo sshd -T | grep -iE 'allowagentforwarding|x11forwarding'

Expect:

allowagentforwarding no
x11forwarding no

Then confirm from the client — this should connect but leave no agent socket behind:

ssh -A youruser@host 'echo $SSH_AUTH_SOCK'

Expect empty output. If it prints a socket path, forwarding is still permitted.

Before you apply this

Low lockout risk — these directives don’t affect whether you can authenticate, only what a session may do afterwards.

The realistic breakage is automation that relies on -A to reach a further host: deploy scripts and CI jobs that hop through a bastion will start failing at the second hop. Grep your automation for ssh -A and ForwardAgent yes before applying this to a jump host, and move those callers to ProxyJump.

Related

• Require key-only SSH authentication — the key this protects.