Windows

PuTTY Migration

Move from PuTTY sessions and PPK files to modern OpenSSH workflows.

Short answer

PuTTY Migration covers the platform-specific details that make SSH work reliably on Windows. The goal is to get connected, verify the service, and avoid weak defaults.

What you will learn

Session mapping
PPK conversion
SSH config

Why this matters

PuTTY Migration matters because Windows is now a first-class SSH environment. Teams often mix Windows laptops, PowerShell automation, Windows servers, and Linux targets, so SSH needs to behave consistently across them.

Set up SSH correctly on Windows before handing the machine to users or automation.

Verify that the SSH client, server, keys, and firewall rules agree with each other.

Troubleshoot connection failures using service status, logs, and verbose SSH output.

Document the working setup so teammates can reproduce it.

How it works

Modern Windows includes OpenSSH client support and can also run an OpenSSH server. Windows Terminal and PowerShell make SSH workflows feel native instead of requiring old session managers.

The biggest differences are paths, service management, key permissions, and agent behavior. A command copied from Linux may need small changes for Windows file paths or services.

Migration from PuTTY should be deliberate: convert keys, preserve host definitions, and move repeatable connection details into OpenSSH-compatible configuration.

Practical example

The exact command or configuration depends on your operating system and security policy, but this pattern is a useful starting point for understanding the workflow.

puttygen key.ppk -O private-openssh -o id_ed25519
ssh -i id_ed25519 [email protected]

Always test examples in a non-critical session first. SSH server settings can lock you out if authentication, firewall, DNS, or host key state is not understood.

Production checklist

Confirm whether the OpenSSH client and server features are installed.

Store keys in the user .ssh directory and check file permissions.

Use Windows Terminal profiles for common destinations instead of scattered shortcuts.

Test PowerShell scripts without printing private paths or secrets into logs.

Common mistakes

Changing server settings before confirming the current client, service, and firewall state.
Testing only from localhost and forgetting real network paths, DNS, or NAT behavior.
Skipping documentation, which makes the next teammate rediscover the same setup.

Troubleshooting signals

ssh is not recognized

Check Windows optional features and PATH. Recent Windows versions usually include the client, but older images may not.

Key permission warnings

Windows file ACLs can be too broad for OpenSSH. Restrict key access to the intended user.

PuTTY key does not work

PPK files often need conversion to OpenSSH format before use with the native ssh command.

Security notes

Validate host fingerprints before trusting a new server.
Prefer key-based access and disable weak authentication where possible.
Keep a second verified admin path open when changing SSH server settings.

Use SSH Bridge when this becomes a team workflow

SSH Bridge gives Windows users a consistent SSH workspace alongside macOS and Linux teammates, reducing reliance on per-machine PuTTY sessions or local-only terminal profiles.

Download SSH Bridge