A repeatable method for SSH problems on Windows

Random fixes waste an hour. Testing the stack in order finds the fault in about five minutes, and every command below runs in a stock PowerShell window with no extra tools installed.

Step 1 — resolve the name

Resolve-DnsName host.example.com

A wrong or missing record explains a surprising share of tickets, especially after a cloud migration.

Step 2 — reach the port

Test-NetConnection host.example.com -Port 22

TcpTestSucceeded True means the network is fine and the problem is authentication or the client. False means stop here and look at firewalls, VPN state and routing.

Step 3 — try a second client

Run ssh user@host with the built-in Windows OpenSSH client. If that works and PuTTY does not, the fault is in the PuTTY session profile — usually a stale key file path or a proxy setting.

Step 4 — read the verbose output

ssh -vvv user@host.example.com

The verbose log names the exact authentication method that failed, which turns a vague permission denied into a specific fix.

Step 5 — check the Windows side

Is the corporate VPN actually connected?
Did a Windows update reset a firewall profile?
Is an endpoint agent inspecting outbound traffic?
Does the same session work from a phone hotspot? That isolates the network instantly.

Questions people ask about this

The connection works at home but not in the office. What now?

Almost always egress filtering on port 22. Ask the network team, or use a jump host that listens on a permitted port.

Everything tests fine but logins are slow.

Usually a reverse DNS lookup timing out on the server side, not a client problem.

Independent guide. Software names belong to their respective developers; always download from the vendor's own site. Back to all Windows SSH guides.