X11 forwarding over SSH lets you run a graphical application on a Linux server and see its window on your local machine. It makes sense when you need a one-off graphical tool and your client has an X server. Use ssh -X by default, -Y only with fully trusted servers, and set X11Forwarding yes in sshd_config.
ssh -X vs ssh -Y: what changes in OpenSSH X11 forwarding
ssh -X enables X11 forwarding and treats remote applications as untrusted, subject to the controls of the X11 SECURITY extension. ssh -Y enables trusted X11 forwarding and drops those controls. Either way, X traffic is encrypted inside the SSH session and the server sets DISPLAY so windows reach your screen.
The difference is about security. The ssh manual page warns that anyone able to bypass file permissions on the remote host can reach your local display through the forwarded connection and, for example, monitor keystrokes. With -Y that access is unrestricted; with -X it is limited, at the cost of some applications breaking.
- Use
-Xby default, and always on shared hosts or servers you don't administer. - Use
-Yonly when the application fails under-Xand you fully trust the server. - Check
ForwardX11Trustedin the system-widessh_config: some distributions change it, and then-Xbehaves like-Y.
How to enable X11Forwarding on the SSH server and test it
The server only accepts X11 forwarding when /etc/ssh/sshd_config contains X11Forwarding yes and the xauth program is installed; if either is missing, the client's request is refused. This is the minimum setup on both ends:
# Server: /etc/ssh/sshd_config
X11Forwarding yes
X11UseLocalhost yes
# Check syntax and reload the service
sudo sshd -t
sudo systemctl reload sshd # on Debian/Ubuntu the service is called ssh
# Client: one-off connection
ssh -X user@server
echo $DISPLAY # something like localhost:10.0
xclock &
# Client: ~/.ssh/config
Host lab
HostName lab.example.com
User user
ForwardX11 yes
ForwardX11Trusted no
The documented sshd_config directives cover the rest: X11UseLocalhost yes binds the forwarded display to the server's loopback interface only, and X11DisplayOffset sets the first display number sshd hands out, hence the usual :10. When something breaks, ssh -v -X user@server tells you why:
X11 forwarding request failed on channel 0: the server hasX11Forwarding noor lacksxauth.Can't open displayfrom the application: usuallyDISPLAYis empty because the session never requested forwarding, or no local X server is running.
X11 forwarding on iOS and Android vs desktop: what each side needs
X11 forwarding needs an X server on the client machine, because that machine draws the windows. A Linux desktop usually has one; macOS needs XQuartz installed; a mobile SSH client is normally a terminal with no X server.
| What is measured | Desktop with ssh -X | iOS/Android phone | Alternative: -L tunnel or SFTP |
|---|---|---|---|
| Local X server | Required: X11, XWayland or XQuartz | Usually not available in the terminal | Not needed |
| Works with Mosh | Mosh doesn't forward X11; needs SSH | Mosh keeps the terminal, no X windows | The -L tunnel needs SSH, not Mosh |
| Switching from wifi to mobile data | SSH session and its windows drop | With Mosh and tmux the session survives | Tunnel reopens; tmux keeps processes alive |
| Risk to the local machine | With -Y, unrestricted display access | No X display exposed | Only the forwarded port is exposed |
| Best fit | One-off graphical tool on a stable network | Terminal administration and files | Web interfaces, charts and documents |
termi1 is an SSH, Mosh and SFTP terminal, and Mosh by design does no port forwarding and no X11 forwarding. What it solves on a phone is different: keeping the session alive when you move from wifi to mobile data, and getting back to tmux with whatever you left running.
4 alternatives to SSH X11 forwarding that work from a phone
ssh -L forwards a local port to a service on the server and covers many cases that used to mean an X window: web dashboards, notebooks or admin consoles listening on localhost.
# Forward the server's port 8080 to your machine
ssh -N -L 8080:localhost:8080 user@server
# Then open http://localhost:8080 in your local browser
- Port tunnel with
ssh -L: shows server web interfaces in your local browser, no X server, in any client that supports port forwarding. - Download the output over SFTP: if the graphical app was only for viewing a chart, a PDF or an image, generate the file on the server and pull it. termi1's built-in SFTP does this without leaving the session.
- Text tools inside tmux:
htop,journalctlor a terminal editor replace many graphical monitors. termi1's keyboard adds Esc, Ctrl and F1–F12, which these tools use constantly. - Remote desktop over a private network: if you need a full desktop, a Prialo private mesh network or Tailscale reaches the machine without a public IP or open ports.
When SSH X11 forwarding still makes sense in 2026
X11 forwarding pays off when three conditions hold: the graphical application only exists on the server, you need it briefly, and you're on a desktop with an X server and a stable network. Outside that case, the alternatives above are simpler and expose less.
Reasonable cases: a graphical installer, a vendor diagnostic tool or a viewer with no web version. Cases to avoid: -Y out of habit, ForwardX11 yes under Host *, or X11Forwarding yes on production servers nobody uses graphically; there, X11Forwarding no is the right setting.
From a phone, the practical flow is to connect with Mosh, reattach tmux and work in text. If you can't recall the ssh -L syntax, the AI in the termi1 SSH and Mosh terminal types the command at the prompt without pressing Enter, and on production-tagged connections Production Guard holds back anything that deletes, stops or changes something.
Frequently asked questions
What is the difference between ssh -X and ssh -Y?
The difference between ssh -X and ssh -Y is the level of trust. -X forwards X11 while applying X11 SECURITY extension restrictions to remote applications; -Y treats them as trusted and gives them full access to your local display. Only use -Y with servers you control.
Why does SSH say X11 forwarding request failed on channel 0?
The message X11 forwarding request failed on channel 0 means the server refused X11 forwarding. The usual causes are X11Forwarding no in /etc/ssh/sshd_config or a missing xauth program on the server. Fix the directive, install xauth, reload sshd and open a new session.
Does X11 forwarding work with Mosh?
X11 forwarding does not work with Mosh. Mosh uses UDP, by default on ports 60000-61000, starts mosh-server through an initial SSH connection, and does no port forwarding or X11 forwarding. To open X windows you need a regular SSH session with -X or -Y.
Can I use X11 forwarding from an iPhone or Android phone?
X11 forwarding from an iPhone or Android phone only works if the client ships an X server to draw the windows, which is uncommon in mobile terminals. In practice, an ssh -L tunnel to a web interface, downloading output over SFTP, or text tools in tmux work better.