WSL SSH Server: Setup and Fix Connection Refused or Timeout

A working SSH command inside WSL does not prove that another computer can reach it. Test the server, the Windows host, and the remote client separately. That sequence helps locate the failure before changing several settings at once.

This guide uses Ubuntu in WSL 2. For the broader workflow from a Mac, see connecting a Mac to WSL 2.

Install and test the server inside Ubuntu

Install the server in the Linux distribution you intend to connect to:

sudo apt update
sudo apt install openssh-server
sudo sshd -t

The last command validates the configuration. Fix any reported errors before restarting SSH. On a distribution with systemd enabled:

sudo systemctl enable --now ssh
sudo systemctl status ssh --no-pager

If systemd is unavailable, start it with sudo service ssh start. Check that a listener exists with ss -ltn, then try ssh YOUR_LINUX_USER@localhost inside Ubuntu. Replace the username with your Linux account, not your Windows account. These commands follow Ubuntu's OpenSSH documentation.

Test from Windows before testing another computer

From a Windows terminal, try:

ssh YOUR_LINUX_USER@localhost

If Windows also runs an SSH server, check which server answered. Run uname -a after login to confirm that the session is Linux. A successful login to Windows can hide the fact that the WSL server remains unreachable.

Record the exact destination, port, username, and error for every test. Comparing those four values is more useful than repeatedly reinstalling OpenSSH.

Choose the correct WSL networking path

Under NAT, a connection from another computer needs a route through Windows to the WSL instance. Microsoft documents port forwarding with netsh interface portproxy; check the current WSL address using wsl.exe hostname -I and inspect existing forwards with netsh interface portproxy show all. A stale destination address is a useful suspect when a connection stops working after restarting WSL.

On supported Windows 11 systems, mirrored networking offers a different route. Microsoft's documentation specifies Windows 11 22H2 or later and the .wslconfig setting:

[wsl2]
networkingMode=mirrored

In this mode, review the Hyper-V firewall rules as well. Allow the SSH port specifically rather than disabling the firewall. Follow Microsoft's WSL networking instructions for your Windows version.

Interpret the error before changing settings

Result	Next check
Connection refused	Is SSH listening on the destination port? Are you reaching the correct host?
Connection timed out	Check the network route, port forwarding, and relevant firewall rule.
Permission denied	The server responded; check the Linux username, key, and authentication settings.
Host key changed	Confirm the machine or distribution was rebuilt before replacing the saved key.

Use ssh -v YOUR_LINUX_USER@DESTINATION to see which stage fails. Save a short diagnostic note with the last successful hop. For example, “Ubuntu localhost works; Windows localhost works; Mac to Windows IP times out” points the investigation toward the external path.

Keep the working setup reproducible

Once the connection works, write down the networking mode, server port, forwarding destination, and allowed client network. Test key authentication before disabling passwords, and validate SSH configuration before restarting the service. Keep the first session open until a second session succeeds.