SSH agent forwarding vs copying a key: what actually leaks

Two different events get called a leaked SSH key, and they call for different responses. Public-key authentication sends a public key and a signature made with the private key, so the private key is never a field in the request. Agent forwarding exposes something else, because a remote host that can reach your forwarded agent can ask it to sign without ever holding the key. Treating those as one event leads either to a pointless rotation or to a delegation left running.

Public-key login transmits a signature, not the key

The authentication exchange carries the user's public key and a signature over session data. The server checks that signature against the key it already trusts, which is why the private half can stay on the client across an untrusted network. A VPN operator watching the tunnel sees an encrypted SSH session either way.

That describes the protocol, not the trustworthiness of every endpoint on the path. Keep host-identity verification intact, because a client that accepts any host key has abandoned a different control than the one under discussion. A captured session and a captured key are separate findings, and only one of them is a credential loss. Keep the two in separate sentences of the report as well.

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh -o StrictHostKeyChecking=yes [email protected]

The first command prints the public fingerprint so you can compare it with what the server lists. The second makes the host-key check explicit instead of relying on a default nobody read. Run both before you change anything about keys, so the baseline is documented.

Forwarding an agent delegates the ability to sign

With forwarding enabled, a socket appears on the remote host and the local agent answers requests arriving through it. Anyone who can use that socket during the session can authenticate as you to hosts that accept the loaded identities. No private key crosses the network to make that work.

The capability is the exposure, not the file. That is why forwarding belongs to a named task and a named host rather than to every connection a laptop makes. A jump host that relays the connection without a forwarded agent usually removes the need entirely.

ssh-add -l
ssh -o ForwardAgent=no [email protected]
ssh -J [email protected] [email protected]

The first lists which identities the agent currently holds, worth knowing before you hand its socket to another machine. The second connects without delegation. The third shows the jump-host pattern that often replaces forwarding altogether.

Choose the response from the evidence you have

A signing identity that is believed exposed calls for the replacement and revocation process, and for removing its acceptance from the services that trusted it. Deleting the copy on your laptop leaves every other copy untouched. Start from the services, then clean up the clients.

A temporary delegation problem is narrower. End the forwarding that was not needed, and review which sessions and identities it covered with whoever owns the incident. Key replacement may still follow, but evidence decides that rather than worry.

No observed export proves only that the mechanism you feared did not appear. It says nothing about what else a host on the other end of that socket could have done.

Keep the controls distinct in the write-up

Protect the private material, limit who can ask it to sign, keep verified peer identity. Those are three controls that reinforce each other, and none of them substitutes for another when you explain what happened.

A compromised laptop or a privileged application on it is a third case with a much wider blast radius. Changing the VPN route does not resolve it, and it does not restore trust in a key that may have been read from disk.

Write down which component was trusted, whether forwarding was on, and what was actually observed. That record is what makes the next decision defensible instead of a guess about what a leak means.