PuTTY saved sessions with Pageant agent forwarding through a bastion

Problem and takeaway

A Windows workstation needs repeated SSH access to Linux hosts behind a bastion. A common failure is copying private keys onto the bastion so internal hosts can be reached, or typing passwords for every connection. Both practices spread key material and expose credentials.

The practical alternative is to keep decrypted private keys only on the workstation in Pageant, store connection details in PuTTY saved sessions, and forward the agent through a trusted bastion. The bastion never sees the private key, and no key file is copied to intermediate hosts. The trade-off is that an unlocked or compromised workstation can allow an attacker to use the agent without extracting the key.

Requirements

• Windows workstation running PuTTY and Pageant.
• Private key in PuTTY .ppk format, or an OpenSSH key converted with PuTTYgen.
• Corresponding public key installed on the bastion and on internal Linux hosts.
• Bastion SSH daemon configured to permit agent forwarding.
• Network path from the workstation to the bastion on port 22, and from the bastion to internal hosts.

Smallest suitable design

Create one saved session for the bastion. In PuTTY, enter the bastion hostname and port, the auto-login username, and the path to the .ppk private key under Connection > SSH > Auth. Enable "Allow agent forwarding" on the same Auth page. Set the host-key policy to warn before accepting unknown keys.

Start Pageant, load the .ppk, then start PuTTY and load the saved session. PuTTY authenticates to the bastion using the key held by Pageant. From the bastion shell, SSH to internal hosts; the forwarded agent supplies the identity, so no password is needed and no key file exists on the bastion.

If the goal is to reach a specific internal service rather than a shell, add a local port forward in the saved session under Connection > SSH > Tunnels: source port on the workstation, destination as internal host and port. Traffic for that port travels through the bastion session.

Example saved-session values

PuTTY category	Setting	Example value
Session	Host Name	bastion.example.com
Session	Port	22
Connection > Data	Auto-login username	deploy
Connection > SSH > Auth	Private key file for authentication	C:\Keys\deploy.ppk
Connection > SSH > Auth	Allow agent forwarding	Checked
Connection > SSH > Host key policy	Policy	Warn before accepting

Replace hostnames, usernames, and paths with your own values.

Command-line launch

putty.exe -load Bastion -A

Where to run: Windows workstation, command prompt or PowerShell. Permissions: standard user; no administrator elevation is required for PuTTY or Pageant. Placeholders: replace Bastion with the saved session name. Expected check: PuTTY opens and authenticates without a password prompt if Pageant is running and holds the key. Risk: if Pageant is not running or the key is not loaded, -A has no identity to forward and authentication may fall back to a password prompt or fail.

Trust and data boundaries

• Workstation. Pageant holds the decrypted private key in memory and answers PuTTY agent requests. Saved sessions in the registry may contain usernames and key-file paths, but not the private keys themselves. Windows account access control still protects who can read those entries and use the agent while the session is unlocked.
• Bastion. The bastion receives a forwarded agent socket. It never sees the private key. A compromised bastion can abuse the forwarded agent while the connection is alive, so enable agent forwarding only on bastions you trust.
• Internal host. Authentication completes with public-key cryptography. The host never receives the key file, only a signature challenge response.

Operational checks

1. Open PuTTY, load the saved session, and confirm Connection > SSH > Auth > Private key file for authentication points to the intended .ppk.
2. Run pageant.exe, load the same key, then connect to the bastion. Confirm login completes without a password prompt.
3. From the bastion, connect to an internal host. Confirm the forwarded identity is accepted without copying a key to the bastion.
4. On first connection to any host, compare the displayed host-key fingerprint against the value published by the server administrator before accepting. PuTTY warns on unknown keys by default; do not silently accept in strict environments.
5. Inspect HKCU\Software\SimonTatham\PuTTY\Sessions with regedit to review saved session names and stored paths. This is a read-only review of configuration, not key material.

Failure modes

• Pageant not running or key not loaded: PuTTY prompts for a password or authentication fails.
• Bastion sshd_config has agent forwarding disabled: authentication succeeds to the bastion, but internal hosts reject the forwarded identity.
• Host key changed or mismatched: PuTTY aborts or warns depending on the per-session policy. Treat unexpected changes as a possible man-in-the-middle event.
• .ppk file moved or deleted: PuTTY cannot use the key from the saved session, although Pageant may still hold a separately loaded copy.
• Any user with access to the unlocked workstation can use the Pageant agent without extracting the key file.

Rollback

Client-side saved-session changes do not alter server state. If you change the bastion's sshd_config to enable AllowAgentForwarding yes, rollback by setting it to no and restarting the SSH service. Verify by attempting agent forwarding again; it should be refused.

Conditions that would change the design

• Untrusted bastion: do not enable agent forwarding. Use separate keys per host or local port forwarding instead.
• Many internal ports or dynamic access: use PuTTY dynamic SOCKS proxying rather than individual port forwards.
• SSH policy requires specific ciphers, key exchange, or key types: set per-session cipher and KEX preferences and verify the installed PuTTY release supports them before relying on them.
• Non-interactive automation: prefer Plink with the same saved session over the PuTTY GUI.

Limitation

Agent forwarding forwards the ability to use the key, not the key itself, but it does not remove risk from the workstation. If the workstation is compromised while Pageant is unlocked, an attacker can authenticate through the agent. Confirm the result by checking that internal hosts accept logins without a password and that no private key file exists on the bastion.