SSH X11 Forwarding Issues: Works for WSL but not Remote Host

SSH X11 forwarding fails on a remote host while working in WSL because the local X server (VcXsrv) is blocking external connections due to default access controls. To resolve this, you must configure VcXsrv to allow non-local clients by enabling "Disable access control" during its startup wizard or via command-line flags. This setting permits the SSH tunnel from the remote Linux machine to connect to your Windows display server, which is otherwise restricted to localhost only for security reasons.

Understanding the Access Control Barrier

By default, modern X servers like VcXsrv are configured with strict access controls to prevent unauthorized applications from drawing windows on your screen. When you run an application via SSH X11 forwarding, the remote server attempts to connect to your local X server using a specific display number (e.g., :10). If the local X server does not explicitly permit connections from the IP address of the SSH client, the connection is rejected. This behavior explains why it works in WSL but fails for a remote host. WSL shares the same network namespace and loopback interface as the host or runs in a way that appears as localhost to the X server. In contrast, a true remote host connects over the network, triggering the firewall-like restrictions within VcXsrv. The error message typically seen in the terminal is X11 connection rejected because of wrong authentication or simply a black window appearing when launching GUI applications.

Configuring VcXsrv for External Connections

The primary solution involves adjusting the settings in VcXsrv to accept connections from any IP address on your local network. You can achieve this either through the graphical wizard or by modifying the launch parameters.

Using the XLaunch Wizard

When starting VcXsrv, use the XLaunch utility instead of the desktop shortcut to access configuration options. Follow these steps:

1. Open XLaunch from the Start menu.
2. Select Multiple windows or One large window depending on your preference.
3. In the Display settings page, ensure the display number matches what SSH expects (usually 10).
4. Critical Step: On the Extra settings page, check the box labeled Disable access control.
5. Click Save configuration to generate an .xlaunch file, then click Next to start the server.

Checking "Disable access control" removes the requirement for xauth tokens from connecting hosts. While this reduces security slightly, it is necessary for X11 forwarding to function across different machines on the same network. If you forget to check this box, the server will reject connections from the remote SSH session.

Command Line Configuration

If you prefer running VcXsrv from the command line or a script, you can pass the flag directly. Use the following command to start the server without access control:

vcxsrv :10 -ac -listen tcp

The -ac flag stands for "access control," and omitting it or explicitly disabling it allows any client to connect. The -listen tcp flag ensures the server listens on TCP ports, which is required for SSH forwarding over a network. Without -listen tcp, VcXsrv may only listen on named pipes or Unix sockets, which SSH cannot utilize.

Verifying SSH Configuration

Once VcXsrv is correctly configured, you must ensure your SSH client is requesting X11 forwarding. Check your SSH configuration file located at ~/.ssh/config or use the command line flag. Add the following line to your ~/.ssh/config file for the specific host:

Host myremotehost
    HostName 192.168.1.50
    ForwardX11 yes
    ForwardX11Trusted no

Alternatively, add the -Y flag (trusted forwarding) or -X flag (untrusted forwarding) when connecting:

ssh -X user@myremotehost

The -Y flag is often more reliable if you encounter permission errors, as it treats the forwarded application as trusted. However, -X is the standard secure method. Ensure that the xauth package is installed on both your local WSL/Ubuntu environment and the remote server, as it manages the authentication cookies required for the display connection.

Troubleshooting Common Errors

Even with correct VcXsrv settings, other issues can prevent X11 forwarding from working. Here are common scenarios and their fixes.

Firewall Blocking Port 6010+

Windows Firewall may block incoming connections on the dynamic ports used by X11 forwarding. By default, X11 uses port 6000 + display_number. If you use display :10, the server listens on port 6010. Create an inbound rule in Windows Defender Firewall to allow TCP traffic on these ports. For simplicity, allowing all incoming TCP traffic on high-numbered ports is often sufficient for development environments, though less secure.

Different Network Subnets

If your remote host is on a different subnet than your Windows machine, ensure that routing is possible. You can test connectivity by pinging the Windows IP address from the remote Linux machine. Additionally, verify that the SSH connection itself is established correctly. Refer to our guide on Troubleshooting kex_exchange_identification Error in Linux SSH Connection if you face initial handshake failures before even reaching the X11 stage.

WSL vs. Remote Host Differences

It is important to note that WSL2 has improved networking capabilities, but it still relies on the underlying Windows network stack. If X11 works in WSL but not on a separate physical machine, the difference is almost certainly the VcXsrv access control setting or Windows Firewall rules. For users comparing PuTTY and Command Prompt behaviors, see SSHX11 doesn't work with Windows 11 cmd, works with PuTTY for insights into client-side handling differences.

Security Considerations

Disabling access control in VcXsrv allows any device on your local network to potentially draw windows on your screen. This poses a risk if your network is untrusted. To mitigate this, consider using SSH tunnels exclusively rather than exposing VcXsrv to the entire LAN. However, for standard home lab setups where you trust the local network segment, disabling access control is the accepted workaround for seamless X11 forwarding. Always restart VcXsrv after changing these settings to ensure they take effect.

Frequently Asked Questions

Why does X11 forwarding work in WSL but not on a remote PC?

It works in WSL because the connection often appears as localhost or shares the same network context that VcXsrv trusts by default. A remote PC connects via a different IP address, which triggers VcXsrv's default access control restrictions unless explicitly disabled.

What is the exact checkbox name in VcXsrv to fix this?

In the XLaunch Extra Settings page, you must check the box labeled "Disable access control". Do not confuse this with "Disable native OpenGL" or other performance options; the access control setting is the critical one for network connectivity.

Can I use xauth instead of disabling access control?

Yes, you can manually manage xauth credentials, but this is complex and error-prone across different sessions. Disabling access control (-ac) is the standard practical solution for most users who need convenient X11 forwarding from multiple sources.

Does VcXsrv need to be running on the same machine as the SSH client?

No, VcXsrv must run on the machine displaying the GUI (your Windows PC), while the SSH client runs on the remote server. The SSH client forwards the display requests back to your Windows machine where VcXsrv is listening.

How do I verify VcXsrv is listening on TCP?

You can check if VcXsrv is listening on TCP ports by running netstat -an | findstr 6010 in PowerShell. If you see a LISTEN state on port 6010 (or your chosen display number), it is ready to accept connections. If it only shows UDP or no entry, restart VcXsrv with the -listen tcp flag.