X11
This page is your cheat sheet. Dig into FAQs and learn what each X11 config file actually does — no fluff, just facts.
Yes.
X11 was designed to use TCP/IP from the start.
It sends display commands over the network on port 6000 + display number.
Not built-in.
SSH wraps around it using a feature called X11 forwarding:
• SSH sets the DISPLAY variable on the remote machine
• Opens a socket (not a TCP port)
• Tunnels everything back to your local X server securely
So yeah — it’s a smart workaround, and it works well with OpenSSH.
No — X11/Xorg screen forwarding over TCP is not encrypted by default.
TCP-based X11 Forwarding (e.g. xhost +, DISPLAY=remotehost:0)
• Protocol: Raw X11 over TCP (port 6000+)
• Encryption: ❌ None
• Security: Extremely insecure — keystrokes, clipboard, windows, even passwords typed in GUI apps can be sniffed
• Typical use case: Legacy, bad practice unless tunneled manually (e.g. over VPN or SSH)
Not natively.
macOS dropped built-in X11 support, but you can use it via XQuartz.
XQuartz is an open-source X server for macOS that enables X11 apps and SSH X11 forwarding.
No.
Windows doesn’t have native X11 or TCP-based GUI.
DISPLAY is an environment variable that tells X11 apps where to draw windows.
Format:
DISPLAY=hostname:display.screen
Examples:
• :0 → Local display 0, screen 0 (default)
• localhost:10.0 → Used when X11 is forwarded over SSH
• 192.168.1.100:0 → Remote X server at that IP, display 0
When you do:ssh -X user@host
SSH sets:DISPLAY=localhost:10.0
Then all GUI traffic is tunneled through SSH and appears on your local screen.
The key setting is:-listen tcp
Nope.
Most modern X11 servers disable TCP by default for security reasons.
They run in Unix socket-only mode, which is local-only.
Depends on the platform.
On Linux (Xorg):
You can launch X manually with:startx -- -listen tcp
Or modify your X session manager’s config to remove -nolisten tcp.
xhost is a command used to control who can connect to your X11 server.
Think of it like a basic access list (firewall-style) for X windows.
Examples:
• Allow a specific IP:xhost +192.168.1.50
• Allow everything (⚠️ not safe, but useful in labs):xhost +
• Revoke all access:xhost -
• Check who’s allowed:xhost
• The X client (the app) runs on the remote server
• The X server (which draws the GUI) runs on your local machine
• The remote app sends drawing commands, not images or pixels
• Your local X server renders the interface using your local GPU (if available)
To receive and display windows from remote apps, your system must be running an X server.
Examples:
• macOS → XQuartz
• Windows → VcXsrv or Xming
• Linux → Xorg (usually running by default)
❌ X11 is not persistent.
If the connection between the X client and X server is lost, the app crashes.
🧠 Why?
X11 apps rely on a live, open socket to the X server.
If that link dies, the app gets a "broken pipe" and exits immediately.
Yes — but not with regular X11 alone.
Tools that keep GUI apps alive even when disconnected:
• VNC — Full virtual desktop
• XPRA — Like screen/tmux but for GUI apps
• Xvfb + x11vnc — Headless setup
• Waypipe — For Wayland (experimental)
You can run GUI apps (like Burp Suite) without a full desktop environment.
They’ll open without borders or controls, but still work if your X server is running locally.
Check current DPI:
xdpyinfo | grep resolution
xrdb -query | grep dpi
To set DPI for scaling apps:
echo "Xft.dpi: 220" >> ~/.Xresources
xrdb -merge ~/.Xresources
DPI controls how big things appear.
• Higher DPI → Bigger, easier to read
• Lower DPI → Smaller, might look tiny on Retina/4K screens
DISPLAY=localhost:10.0 — Tells apps where to draw (set by SSH)
XDG_RUNTIME_DIR=/run/user/1003 — Temporary session path
XAUTHORITY=~/.Xauthority — X11 auth (optional)
Xft.dpi=220 — DPI setting (if configured)
Runs when you log in via GUI or use ssh -X. Lets you pick what desktop or window manager to start (like i3, xfce, etc). Also a good place to set environment variables.
Stores special authentication "cookies" that let remote apps securely draw on your screen during ssh -X.
❗️If this is missing or wrong, X11 forwarding won’t work — you’ll get Can't open display errors.
Controls how X11 apps look — like fonts, DPI, and colors.
If your terminal text is too small over ssh -X, this file can fix it.
Loaded with xrdb when X starts.
This script directly controls how the X server is launched with startx.
You can add options here like -listen tcp to enable remote GUI access.
⚠️ If ssh -X fails with "connection refused" or GUI windows won’t show — this file is the first place to check and edit.
Main (optional) config for the X server.
Lets you hardcode things like screen layout, input devices, and video drivers.
Not usually needed unless you’re doing something custom or advanced.
Modern replacement for xorg.conf.
Contains smaller, modular config files that override or extend X11 settings.
You can drop in a new file just to configure a touchpad, keyboard, etc.
X server log file — shows you exactly what’s happening when X starts.
If ssh -X or startx fails, look here first for clues.
Search for lines starting with (EE) to find errors.