Headless Server X11 Forwarding To Local Display Using Ssh Port Tunneling

Enabling X11 Forwarding on SSH Server

The first step in setting up X11 forwarding from a headless Linux server to your local machine is to enable X11 forwarding in the SSH daemon’s configuration file on the server. By default, X11 forwarding is disabled for security reasons on most SSH server implementations.

On a Linux system running OpenSSH as the SSH server, you can enable X11 forwarding by editing the OpenSSH daemon configuration file /etc/ssh/sshd_config. Using elevated privileges such as with the sudo command or as root, open /etc/ssh/sshd_config in a text editor.

Find the line that reads:

X11Forwarding no

And change the value to yes:

  
X11Forwarding yes

This option specifies whether X11 forwarding is permitted or not. Setting it to “yes” means that the SSH server will allow clients to forward X11 connections back to their local machines. The server must also have X11 libraries and applications installed to actually generate graphical output.

After saving the changes to sshd_config, the OpenSSH daemon must be restarted to load the new configuration:

$ sudo systemctl restart sshd

Or if running an older Linux distribution:

$ sudo service ssh restart 

Now X11 forwarding connections will be allowed by the SSH daemon on incoming SSH connections.

Configuring SSH Client for X11 Forwarding

With the SSH server now configured to allow X11 forwarding, client configuration is required to enable forwarding on SSH sessions from your local machine to the remote host. This tells SSH to tunnel the X11 traffic back to your local display rather than trying to open graphical windows on the remote server itself.

In the SSH client, the -X option is used to enable X11 forwarding over SSH. Using OpenSSH as an example, connect with:

$ ssh -X user@remotehost

The -X sends the X11 traffic back through the SSH connection to your local machine. Note that on some distributions the default SSH client configuration has X11 forwarding enabled already, so explicitly passing -X may not be necessary.

You will also need to set the DISPLAY environment variable to tell applications to render graphics back to your local X11 server display. Typically in Linux this would be “:0” signifying the first local display:

  
$ export DISPLAY=:0

Optionally, you can execute the echo command to verify the DISPLAY variable is set properly:

$ echo $DISPLAY
:0

With X11 forwarding now enabled in SSH and the DISPLAY variable set, graphical applications launched from the remote SSH session will be sent back to your local machine rather than opening windows on the remote server desktop.

Connecting to Headless Server Graphical Programs

For additional security or firewall traversal reasons, sometimes direct X11 forwarding alone does not work properly or port 6000 UDP traffic is blocked between networks. In these cases, SSH tunneling via port forwarding can redirect and encapsulate the X11 traffic securely through the encrypted SSH connection.

The ssh command on most Linux/Unix systems includes a -L option to specify port forwarding tunnels. The basic syntax is:

ssh -L :: user@host

This means tunnel the remote port to the specified local listening port on the client machine. The connection from the local port is forwarded through SSH back to the specified port/host on the remote server.

To utilize this for X11 forwarding, you need to tunnel remote port 6000 to a local port 6000 with something like:

$ ssh -L 6000:localhost:6000 -X user@remotehost

Breaking this down:

• -L 6000:localhost:6000 – Forwards remote port 6000 to local port 6000
• -X – Enables X11 forwarding on the SSH client side
• user@remotehost – Connects to the remote server

Then launch GUI applications as normal on the remote host, but the X11 traffic will be tunneled securely through SSH back to port 6000 on your local machine before routing to your display server.

For example, to launch xclock:

$ xclock

The application appears to run on the remote server, but displays on your local desktop rather than the remote machine thanks to the port forwarding tunnel transporting the graphical commands.

Troubleshooting Issues with X11 Forwarding

Sometimes X11 forwarding fails to generate graphics properly on the local machine. There are a few common issues and troubleshooting steps to try.

Firewall allowing port 6000 – Be sure firewall rules allow outbound UDP port 6000 traffic from the remote server back to your client machine’s IP address. This graphical traffic must initiate from the server for security reasons.

Basic X11 check without tunnels – Verify a simple X11 forwarding session works without port forwarding tunnels using just ssh -X user@remotehost and launching xclock. Get basic forwarding working first before tunneling the port.

X Window System required locally – Your local machine must have X Window System libraries and applications installed to process and render the graphical output being sent back from the remote host. Verify a valid display server is running locally.

Try SSH compression – Using SSH compression with the -C option can improve performance for X11 forwarding on slower connections: ssh -CX user@remotehost. This reduces bandwidth needed.

Switch to VNC – On very slow connections, even with compression X11 can still perform poorly. In these cases, consider switching to use VNC for remote access which includes optimizations for low bandwidth/high latency links.