SSH Key Copied or Agent Forwarded? Two Different Risks

A login that uses an SSH key through a VPN does not mean the private key was handed to the network operator, and that reassurance is narrower than people hear it. Public-key authentication sends a public key and a signature the client produces locally. Agent forwarding is a different arrangement with a different exposure, and it can leave a usable authentication capability on a machine you do not control. The response you owe depends on which of those two actually happened.

What Public-Key Authentication Sends

In the standard public-key method the client offers a public key, the server decides whether it accepts that key, and the client signs a challenge with the private key, which stays in its file or its agent. What crosses the network is the public key and the resulting signature. Nothing in that exchange requires the server, the tunnel, or anyone along the path to hold the private material.

The authentication specification defines that proof, and the private key is not a field in the request.

That is a statement about a protocol, not a character reference for every endpoint involved. Host identity checking still has to be intact, because a server that cannot prove who it is may be collecting signatures for a purpose you did not intend. A rented VM, an inherited bastion and a laptop running an unfamiliar extension are three separate trust questions. Keep them separate from the cryptographic one, which is genuinely settled.

What Agent Forwarding Delegates

Agent forwarding opens a channel from the remote host back to the agent on your machine, so processes on that host can ask the agent to sign without ever holding the private key. The key stays where it is and the capability does not. Anything able to reach that forwarded socket on the remote host, for the life of the session, can request authentication operations as one of the loaded identities. That is delegated authority, which is why forwarding deserves a narrower policy than handing over a public key.

A copied key file is a disclosure. A forwarded agent is a grant, and the two need different answers.

Enable forwarding for a named need and named hosts, and check what the client actually does rather than what the configuration appears to say. Effective settings are what matter, because a host block quietly overrides a global default. The same reasoning applies at the server end, which can refuse forwarding entirely when the deployment never needs it.

Read the Evidence Before Choosing a Response

If a private key file or an equivalent signing identity is believed exposed, the response is replacement and revocation through your organisation's process, plus removal of its acceptance from every service that trusted it. Deleting one local copy does not invalidate the copies you cannot see.

If the concern is temporary agent access, the response is narrower: stop the unnecessary delegation, review the sessions and identities involved, and let the incident owner decide whether replacement is warranted. Evidence matters here, because no observed export does not prove that no authentication was misused, and a path change alone is not a diagnosis of a stolen key. Write down which component was trusted, whether forwarding was enabled, and what was actually observed. Then choose the response that fits that record instead of the most dramatic one available.

ssh-add -l
ssh -G host.example | grep -i forwardagent

Run those before and after a change so the comparison means something. A session established earlier keeps the delegation it was granted, whatever the settings say now.

Two Controls That Are Not Interchangeable

Protecting private material, limiting who can ask it to sign, and verifying peer identity are three related controls, and none substitutes for another. A team that removes forwarding without checking host keys has fixed half a problem. A team that rotates a key because the route changed has fixed none.

A compromised endpoint is a fourth question, because privileged software on your own machine can do considerably more than observe packets.

Sort the incident into those categories before touching anything, and give each one an owner. Keep a short record of what was trusted, what was delegated and what was verified, since that record is what makes the next review cheap instead of another debate. If any category is unknown, write unknown rather than assuming the benign case. The distinction is practical rather than academic: it decides whether you replace a credential, revoke a session, or simply stop forwarding.