ssh client with the appropriate user and command arguments. By treating the WSL instance as a distinct network endpoint, you can streamline automation scripts and remote administration tasks without launching interactive shells or additional windows.
Prerequisites for WSL SSH Access
Before attempting any connections, ensure that your WSL 2 distribution is properly configured to accept incoming SSH traffic. Unlike the Windows host, which has its own SSH server service, each WSL distribution runs its own independent Linux environment. Therefore, you need to install and configure the OpenSSH server inside the specific distribution you intend to access. First, launch your WSL terminal. You can do this by typingwsl in the Windows Command Prompt or PowerShell. Once inside the Linux shell, update your package lists and install the OpenSSH server package. For Debian-based distributions like Ubuntu, use the following commands:
sudo apt update
sudo apt install openssh-serversudo ssh-keygen -A to create these necessary files. Next, start the SSH service manually to verify it works. Use sudo service ssh start. If the service starts successfully, you are ready to proceed with configuration.
It is crucial to note that WSL instances are ephemeral. The SSH service will not automatically restart after a WSL shutdown unless configured to do so. To make the service persistent across reboots, you may need to adjust startup scripts or use systemd if available in your specific WSL version. However, for immediate testing, manual starting is sufficient.
Configuring Network Connectivity
WSL 2 uses a virtualized network interface, which means it has a dynamic IP address assigned by the Hyper-V virtual switch. To connect to it reliably, you need to know the current IP address of your WSL instance. Inside the WSL terminal, runhostname -I to display the IP address. Note that this IP may change every time you restart WSL.
If you prefer a static internal IP or want to avoid dealing with changing addresses, you can configure your router's DHCP reservations or use port forwarding rules on the Windows host. However, the simplest method for local development is to query the IP dynamically when needed.
Ensure that the Windows Firewall allows inbound connections on port 22 (the default SSH port). While WSL traffic often bypasses some Windows firewall checks due to its virtualization layer, it is good practice to verify that no blocking rules are active. You can check this by running netsh advfirewall firewall show rule name=all | findstr 22 in PowerShell.
For users experiencing connectivity issues, such as "Can't Connect to Localhost," refer to our guide on Troubleshooting SSH WSL Machine: Can't Connect to Localhost. This article details common pitfalls regarding network adapters and firewall settings that often prevent successful SSH handshakes.
Executing Commands Remotely
Once the SSH server is running and you have the IP address, you can execute a single command from the Windows command line. The syntax mirrors standard SSH usage but targets the WSL IP. Open your Windows Command Prompt or PowerShell and type:ssh username@wsl-ip-address "command_to_run"username with your valid WSL user account name and wsl-ip-address with the output from hostname -I. The string "command_to_run" should be replaced with the actual bash command you wish to execute. For example, to list files in the home directory, you would use:
ssh [email protected] "ls -la ~"Security Considerations
Running an SSH server in WSL introduces security considerations. Since WSL shares the kernel with Windows, vulnerabilities in the SSH daemon could potentially impact the host system. Always keep your OpenSSH package updated usingsudo apt upgrade openssh-server. Additionally, disable password authentication and use SSH keys instead to prevent brute-force attacks. Edit /etc/ssh/sshd_config and set PasswordAuthentication no if you rely solely on key-based authentication.
Furthermore, consider restricting access to localhost only if you are not exposing the service to other devices on your network. You can bind the SSH server to 127.0.0.1 in the sshd_config file by setting ListenAddress 127.0.0.1. This ensures that only processes running on the Windows host can connect to the WSL SSH server, adding a layer of isolation.
Frequently Asked Questions
Why does my SSH connection time out immediately?
This usually indicates that the SSH service is not running inside the WSL instance. Verify the service status by logging into WSL and running sudo service ssh status. If it is inactive, start it with sudo service ssh start.
Can I use the hostname 'localhost' instead of the IP address?
No, because WSL 2 runs in a lightweight utility VM with its own network stack. 'localhost' refers to the Windows host itself. You must use the specific IP address assigned to the WSL network adapter, which you can find using hostname -I.
How do I handle dynamic IP changes in WSL 2?
Since the IP address changes upon restart, you can write a small batch script or PowerShell function that queries wsl hostname -I and passes that value to your SSH command. This automates the process and eliminates manual IP lookups.
Is it safe to leave the SSH server running all the time?
While convenient, leaving SSH open increases the attack surface. It is recommended to stop the service when not in use (sudo service ssh stop) or configure it to start only when needed. Using key-based authentication further mitigates risks associated with persistent services.
What if I need to run a GUI application remotely?
Standard SSH does not support GUI applications natively. You would need to configure X11 forwarding by setting ForwardX11 yes in the SSH client config and having an X server like VcXsrv installed on Windows. Alternatively, use tools like RDP or VNC for graphical access.