Enable X11 Forwarding over SSH and Set DISPLAY in Linux

Updated: 12 October 2026 · Applies to: OpenSSH 10.2 on Ubuntu 26.04, 10.0 on Debian 13 and 9.9 on AlmaLinux 10, xauth 1.1.2 (tested); Rocky Linux and RHEL use the same configuration as AlmaLinux; clients on Linux, macOS and Windows

X11 forwarding runs a graphical program on a server and shows its window on your own computer, through SSH. Install xauth on the server, connect with ssh -X user@server and start the program. SSH then sets the DISPLAY environment variable to something like localhost:10.0, which tells graphical programs where to draw. Most "cannot open display" errors come down to a missing or wrong DISPLAY, explained below.

What the DISPLAY variable means

DISPLAY names the X server (the "display") that a graphical program connects to. According to the X(7) manual its form is hostname:displaynumber.screennumber; without a host name the program uses a local connection, and without a screen number it uses screen 0.

• :0: the first X server on this machine, reached through the socket /tmp/.X11-unix/X0. This is what a desktop session usually has.
• localhost:10.0: display 10 over TCP on the loopback address, which means port 6010 (6000 plus the display number). SSH creates this for X11 forwarding, starting at display 10 (X11DisplayOffset) so it does not clash with a real X server.
• 192.0.2.5:0: an X server on another machine, port 6000. Current X servers do not listen on TCP by default: our test X server had only its socket open, and DISPLAY=localhost:0 failed with unable to open display "localhost:0". Use SSH forwarding instead of opening port 6000.

Check and set it like any environment variable (see also environment variables in Linux):

echo $DISPLAY           # show the current value
export DISPLAY=:0       # set it for this shell
DISPLAY=:0 xterm        # set it for one command only

Without it, programs stop at once. Lab output from Ubuntu 26.04:

$ xterm
xterm: Xt error: Can't open display:
xterm: DISPLAY is not set
$ DISPLAY=:5 xterm
xterm: Xt error: Can't open display: :5

To start a program on a desktop that is already logged in on the server's own screen (for example from an SSH session), set DISPLAY=:0 and point XAUTHORITY to that desktop user's authority file. With the right display but no access cookie, our test gave Authorization required, but no authorization protocol specified; with XAUTHORITY set, the same command worked. Do not put export DISPLAY=... in ~/.bashrc on a server: it overrides the value SSH sets and breaks forwarding.

Enable X11 forwarding on the server

1. Install xauth, which SSH uses to set up the forwarded display:

   sudo apt install xauth               # Ubuntu, Debian
   sudo dnf install xorg-x11-xauth      # AlmaLinux, Rocky Linux, RHEL

2. Check that forwarding is allowed:

   $ sudo sshd -T | grep -i x11
   x11displayoffset 10
   x11forwarding yes
   x11uselocalhost yes

   OpenSSH's own default is no, but Ubuntu and Debian set X11Forwarding yes in /etc/ssh/sshd_config, and AlmaLinux sets it in /etc/ssh/sshd_config.d/50-redhat.conf. If yours says no, create /etc/ssh/sshd_config.d/x11.conf with the line X11Forwarding yes and restart SSH: sudo systemctl restart ssh (Ubuntu, Debian) or sudo systemctl restart sshd (AlmaLinux, Rocky Linux, RHEL).
3. Install a small program to test with: sudo apt install xterm or sudo dnf install xterm.

Prepare your computer

• Linux desktop: nothing to install; echo $DISPLAY already shows a value such as :0.
• macOS: X11 is no longer part of macOS; Apple refers to the XQuartz project. Install XQuartz, then use ssh -X from Terminal.
• Windows: according to Microsoft, WSL 2 runs Linux graphical apps without a separate X server on Windows 11 and Windows 10 build 19044 or later, so you can run ssh -X from the WSL terminal. Otherwise install an X server for Windows and set DISPLAY to point at it before connecting.

Connect and test

$ ssh -X user@203.0.113.10
$ echo $DISPLAY
localhost:10.0
$ xauth list
myserver/unix:10  MIT-MAGIC-COOKIE-1  <cookie>
$ xterm

This is lab output from a test container (cookie and host name replaced). If a terminal window opens on your screen, forwarding works. On the first login you may see /usr/bin/xauth: file /home/user/.Xauthority does not exist: xauth creates the file, so it is harmless.

• -X or -Y: the OpenSSH manuals describe -X as untrusted forwarding, which limits what the remote program can do on your screen and expires after 20 minutes, and -Y as trusted forwarding with full access. On Debian, Ubuntu and AlmaLinux clients, ssh -G showed forwardx11trusted yes, so there -X already behaves like -Y. Use forwarding only with servers you trust.
• Always on for one server: add to ~/.ssh/config on your computer:

  Host myserver
      HostName 203.0.113.10
      ForwardX11 yes

Common problems

• X11 forwarding request failed on channel 0: the server refuses forwarding. In our tests, both a missing xauth and X11Forwarding no produced exactly this message, and DISPLAY stayed empty. Go through the server steps.
• Warning: No xauth data; using fake authentication data for X11 forwarding.: your own X server has no access cookie for SSH to copy. Forwarding usually still works.
• Error: Can't open display: or an empty DISPLAY with no warning: you connected without -X, or no X server runs on your computer (with no local DISPLAY, ssh -X silently skipped forwarding in our test).
• Works as your user, fails after sudo or su: DISPLAY is passed on, but the access cookie stays in your own ~/.Xauthority, so the program reports unable to open display "localhost:10.0". Copy the cookie to root: xauth extract - "$DISPLAY" | sudo xauth merge -. (Tested from root to another user; it worked straight after the merge.)
• Very slow windows: X11 over the internet suits small tools, not full applications. Add -C for compression, or use a remote desktop: VNC over SSH or xrdp.

Official documentation: ssh manual (options -X and -Y), sshd_config X11Forwarding, X(7) display names.