In this guide
What you need before opening PuTTY
Collect the server hostname or IP address, SSH port, account name, and the expected host key fingerprint from the server administrator. If key authentication is required, you also need a private key that belongs to you. Never ask another user to share theirs.
PuTTY is a third-party SSH client for Windows. PutyGo provides independent education and does not distribute PuTTY. Obtain software only from a source your organization has approved.
- Server hostname, such as server.example.com
- SSH port—usually 22, but not always
- Your individual username
- Expected host key fingerprint
- Private key or password, as authorized
Create and save a basic session
Enter the destination
In Session, enter the host name and port. Select SSH as the connection type.
Name the session
In Saved Sessions, use a descriptive name such as “Production — read only”. Avoid putting passwords or secrets in the name.
Save the settings
Choose Save. Re-select the session and choose Load whenever you want to verify what is stored.
Connect and verify
Choose Open. On first connection, compare the displayed server host key fingerprint with the trusted value supplied out of band.
A first-connection host key prompt is not an instruction to click “Accept” automatically. The fingerprint is how you check that you reached the intended server.
Authentication and username settings
Set an auto-login username under Connection › Data only when the saved session is used by one person. For key authentication, select the private key under Connection › SSH › Auth (the exact label can vary by PuTTY version). The private key remains a sensitive credential even when protected by a passphrase.
Do not save account passwords in shortcuts, scripts, session names, or documentation. PuTTY does not need a stored password to save the rest of a session.
Useful settings for reliable sessions
Load the saved profile before changing these options, then return to Session and choose Save so that the changes belong to that profile.
Configure keepalives
Open Connection and set “Seconds between keepalives” only when a firewall or network device drops an otherwise healthy idle session. A moderate value such as 30–60 seconds is a common starting point when your administrator permits it. “Enable TCP keepalives” is a separate operating-system mechanism and is normally left off unless the network policy calls for it.
Choose session logging deliberately
Open Session › Logging. Select “Printable output” or “All session output” only when you have a documented reason, then choose an approved log-file location. Avoid SSH packet or raw-data logging for routine work. Logs can expose commands, paths, output, and other sensitive information.
Set the remote character encoding
Open Window › Translation and review “Remote character set.” UTF-8 is appropriate for most current Linux and Unix systems, but the server locale is authoritative. If characters display incorrectly, confirm the server encoding before changing this setting.
Add an approved SSH tunnel
Open Connection › SSH › Tunnels. Enter the Source port and choose Local, Remote, or Dynamic as documented. For Local or Remote forwarding, enter the approved Destination in host:port form; dynamic SOCKS forwarding does not use a fixed destination. Select Add and confirm that the rule appears in the forwarded-ports list before saving the session. Leave this list empty when no tunnel has been authorized.
Agent forwarding is different from port forwarding. Depending on the PuTTY version, its checkbox appears under Connection › SSH › Auth or Connection › SSH › Auth › Credentials. Leave it disabled unless the workflow has been explicitly reviewed, because a compromised remote host may attempt to use the forwarded agent.
Save and test the completed PuTTY setup
Return to Session
Select Session at the top of the category tree. Confirm the hostname, port, and SSH connection type.
Save the profile again
Select the intended name under Saved Sessions and choose Save. This records the settings selected in the other categories.
Test without assuming trust
Open the session, verify the host key when required, authenticate with the approved method, and confirm that terminal text, keepalives, logging, and any authorized forwarding behave as expected.
Review saved sessions over time
Saved profiles are configuration, not proof that a destination is still trusted. Review hostnames, usernames, forwarding rules, proxy settings, and identity files when systems or responsibilities change. Delete obsolete profiles to reduce accidental connections to retired environments.