PuTTY SSH Agent Forwarding: Architecture and Operational Boundaries

Requirements

SSH agent forwarding lets a PuTTY client use private keys held by a local authentication agent (typically Pageant on Windows) to authenticate to remote hosts, and optionally to hosts reached from those remotes, without copying private key material to any server. The requirement is to reduce the attack surface: private keys never leave the workstation, and the remote host only sees a socket that can request signatures from the agent.

Typical use cases include bastion-host workflows, CI/CD pipelines that need to pull from private repositories on a build server, and developers who hop through a jump box to reach internal infrastructure. The feature must work with OpenSSH-compatible agents and PuTTY's own Pageant, and it must be opt-in per connection.

Smallest Suitable Design

The minimal configuration consists of three pieces:

1. A running SSH agent that holds the desired private keys. On Windows this is usually Pageant (bundled with PuTTY); on WSL or Linux it can be ssh-agent.
2. In PuTTY, enable Connection → SSH → Auth → Allow agent forwarding (labelled "Allow agent forwarding" in PuTTY 0.78+; earlier versions use "Allow agent forwarding" under the same tree).
3. Ensure the agent's socket is accessible to the PuTTY process. Pageant creates a named pipe (\\.\pipe\pageant.pid) that PuTTY discovers automatically when both run in the same user session.

No server-side configuration is required beyond the standard AllowAgentForwarding yes (the OpenSSH default) in /etc/ssh/sshd_config on the remote host.

Trust and Data Boundaries

The critical trust boundary is the forwarded agent socket. When agent forwarding is enabled, the remote sshd creates a Unix-domain socket (or named pipe on Windows) that tunnels back to the local agent. Any process on the remote host that can read that socket—typically the user's shell and any child processes—can request the agent to sign authentication challenges.

• Local side: The agent only accepts connections from the PuTTY process that launched the session. Pageant does not listen on a network port.
• Remote side: The socket file lives under /tmp/ssh-XXXXXX/agent.pid with permissions 0600 owned by the connecting user. Root on the remote host can access it.

Therefore, agent forwarding should only be enabled for remote hosts you trust to the same degree as your local workstation. If the remote host is compromised, an attacker with access to your user account (or root) can use your keys to authenticate to any other host that accepts those keys.

Operational Checks

Before relying on forwarding in production, verify the chain end-to-end:

1. Agent presence: Start Pageant, add your key (pageant.exe key.ppk), and confirm the key appears in the Pageant tray icon → "View Keys". Note the fingerprint (SHA-256).
2. PuTTY configuration: In the session config, check Allow agent forwarding. Save the session.
3. Connection test: Connect to a test host. Once logged in, run:

   ssh-add -l

   The output should list the same fingerprint shown in Pageant. If it shows "The agent has no identities", forwarding is not working.
4. Key usage audit: On the remote host, ssh -v -A user@next-hop 2>&1 | grep "sign_and_send_pubkey" confirms the agent was asked to sign a challenge.

Failure Modes

Symptom	Likely Cause	Diagnostic Step
PuTTY reports "No supported authentication methods available"	Agent not running, or key not loaded in agent	Check Pageant tray icon; run pageant.exe with key argument
ssh-add -l on remote shows "Could not open a connection to your authentication agent"	Forwarding disabled in PuTTY or blocked by server config	Verify Allow agent forwarding checked; check sshd_config AllowAgentForwarding
Key appears in ssh-add -l but authentication fails on next hop	Key not authorized on target host, or key type unsupported (e.g., DSA on modern OpenSSH)	Check authorized_keys on target; try ssh -v for key type negotiation
Intermittent failures after network glitch	Agent socket stale; PuTTY reconnected but agent channel not re-established	Restart PuTTY session; Pageant retains keys across sessions
Unexpected key used for authentication	Multiple keys loaded in agent; server accepts first matching key	Use IdentitiesOnly yes and IdentityFile in ~/.ssh/config on remote to constrain selection

Conditions That Would Change the Design

• Untrusted remote host: Disable agent forwarding entirely. Use ProxyJump or ProxyCommand with a dedicated bastion key instead.
• Multi-factor authentication (FIDO2, TOTP) required: Hardware tokens and some MFA methods cannot be forwarded. The agent cannot satisfy a challenge that requires local user presence.
• Regulatory or policy prohibition on key forwarding: Some compliance regimes treat forwarded agent access as equivalent to key copies. Replace with short-lived certificates issued by a CA (e.g., ssh-keygen -s ca_key -I id -n user -V +1h user_key.pub).
• Non-interactive automation: For CI/CD runners, prefer deploying a dedicated service account key with restricted command="..." and from="..." options in authorized_keys rather than forwarding a developer's agent.
• Windows session isolation: If PuTTY runs in a different logon session (e.g., scheduled task, service) than Pageant, the named pipe is not reachable. Run both in the same interactive session or use an OpenSSH agent reachable via a local TCP loopback socket (ssh-agent -a 127.0.0.1:2200) with SSH_AUTH_SOCK set.

Verification Checklist for Production Rollout

1. Confirm Pageant (or ssh-agent) starts at logon and loads the correct key set.
2. Lock down the remote host: ensure only authorized users have shell access; consider ForceCommand or restricted shells for service accounts.
3. Enable audit logging on the remote host: LogLevel VERBOSE in sshd_config records forwarded agent connections.
4. Test failure injection: stop Pageant mid-session and verify subsequent hops fail cleanly without falling back to password authentication.
5. Document the approved key fingerprints and rotate them on a schedule; revoke by removing from Pageant and from authorized_keys on all targets.

Version assumptions: PuTTY ≥ 0.78, Pageant bundled with same release, OpenSSH ≥ 8.2 on remote hosts. Behavior may differ with older PuTTY versions (pre-0.70 used a different agent protocol) or with third-party agents like gnome-keyring-daemon.