In this guide
PuTTY or Windows OpenSSH?
PuTTY offers saved graphical sessions and integrates with PuTTYgen and Pageant. OpenSSH uses familiar ssh commands and interoperable configuration files. Organizations can support either or standardize one to simplify documentation.
- Choose PuTTY for a GUI-centered, saved-session workflow.
- Choose OpenSSH for terminal workflows, scripts, and cross-platform consistency.
- Do not convert keys repeatedly unless a real compatibility need exists.
- Use only software versions and installation channels approved by your organization.
Check whether OpenSSH Client is available
In PowerShell or Windows Terminal, run the version command. A response beginning with OpenSSH confirms that Windows can find the client executable; the command does not test connectivity to a server.
Check the installed client
Run this in PowerShell, Command Prompt, or Windows Terminal. If a version is displayed, continue with your approved SSH connection instructions.
ssh -VEnable it through Windows Settings
If ssh is not recognized, open Settings › Apps › Optional features on Windows 10, or Settings › System › Optional Features on Windows 11. Choose View features or Add a feature, find “OpenSSH Client,” and install it. Managed devices may require an administrator or software-management process.
Enable it with elevated PowerShell
Administrators can install the Windows capability with the following command when organizational policy permits it. Reopen the terminal afterward and run ssh -V again.
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0If your organization uses PuTTY instead, follow the PutyGo PuTTY configuration guide to create and save a verified SSH session.
Understand Windows key storage
OpenSSH commonly uses the .ssh folder in your Windows profile. PuTTY commonly uses PPK private keys selected in a session or loaded into Pageant. Restrict private-key file access, protect interactive keys with passphrases, and follow managed backup rules.
Keep known hosts trustworthy
OpenSSH and PuTTY maintain host trust information differently. In either client, an unexpected key change deserves verification. Do not teach users to delete trust records as a generic fix; first confirm why the server identity changed.
Common Windows issues
- Corporate proxy or VPN requirements
- Endpoint security blocking an executable or port
- Wrong username caused by local defaults
- PPK versus OpenSSH private-key format mismatch
- Overly broad or incorrect file permissions
- DNS resolving a different server than expected