Managing Complex SSH Workflows with PuTTY Saved Sessions

The Friction of Manual SSH Connections

Manually entering hostnames, non-standard ports, and navigating through authentication menus every time you connect to a server is a productivity drain. When managing a fleet of servers—some requiring specific proxy tunnels, others requiring unique private keys—the risk of connection errors increases. The solution is PuTTY's Saved Sessions, which allow you to encapsulate the entire connection state into a named profile.

What Constitutes a Saved Session?

A saved session is more than just a bookmark for a hostname. It captures a snapshot of the PuTTY configuration window, including:

• Connection Basics: Hostname, port, and protocol (SSH, Telnet, Rlogin, or Serial).
• Authentication: Paths to private keys and agent forwarding settings.
• Network Pathing: Proxy configurations (SOCKS4/5, HTTP, or local) used to traverse firewalls.
• Environment: Terminal window size, font settings, and logging preferences.

Configuring a Production-Ready Session

To move beyond basic connectivity, configure your session for stability and security. Instead of relying on passwords, use public-key authentication. Navigate to Connection → SSH → Auth and provide the path to your private key file (.ppk). If you need to jump from one server to another, enable Allow agent forwarding in the same menu; this allows the remote server to use your local SSH agent for further connections without storing your private key on the remote host.

For environments with strict egress filtering, go to Connection → Proxy. Select the proxy type (e.g., SOCKS5) and enter the proxy server's address and port. PuTTY will then route the initial TCP connection through this proxy before initiating the SSH handshake.

Worked Example: The Jump-Host Architecture

Imagine a scenario where a Database Server (db-internal.local) is only accessible via a Jump Host (jump.example.com) using a SOCKS5 proxy established by an existing tunnel.

Setting	Value	Location in PuTTY
Host Name	db-internal.local	Session → Host Name
Proxy Type	SOCKS5	Connection → Proxy
Proxy Host	127.0.0.1 (Local Tunnel)	Connection → Proxy
Proxy Port	1080	Connection → Proxy
Auth Key	C:\\keys\\db_admin.ppk	Connection → SSH → Auth

Once these are set, enter "DB-Production" in the Saved Sessions field and click Save. You can now launch this complex connection with a double-click.

Portability and the Windows Registry

PuTTY does not use a configuration file; it stores sessions in the Windows Registry. You can find them at:
HKEY_CURRENT_USER\\Software\\SimonTatham\\PuTTY\\Sessions

To migrate these sessions to a new machine, you must export this registry key as a .reg file. Risk: Manually editing these registry values is discouraged as it can lead to configuration corruption. Always use the Windows Registry Editor (regedit) to export the entire Sessions folder to ensure all associated settings are captured.

Security Trade-offs and Limitations

The primary trade-off in PuTTY is between convenience and security. While you can save passwords within a session, they are stored in plain text in the registry. This is a significant security vulnerability. The professional standard is to use Pageant (PuTTY Authentication Agent), which holds decrypted keys in memory, ensuring that no sensitive credentials reside on the disk in an unencrypted state.

Verifying Your Configuration

To ensure your session is correctly configured before deploying it to a production workflow:

1. Load the saved session from the list and click Open.
2. Observe the terminal window; if the connection hangs at "Connecting to...", verify your Proxy settings or firewall rules.
3. If you are prompted for a password despite having a key configured, check the path to your .ppk file in the SSH → Auth section.
4. To verify proxy usage, check the PuTTY event log (right-click the title bar → Event Log) to see the connection sequence to the proxy address.