What You Need to Know About X11 Forwarding

Last updated: November 2025

In this blog post, we will answer common questions about X11 and X11 forwarding, as well as the security implications of X11 forwarding that any user should understand.

What is X11?

X11 refers to the 11th edition of the X Window System, an open source graphics protocol developed in the early days of the internet. Released in 1987, X11 provides a basic framework for creating custom GUIs that can display graphics on both local and remote display devices.

The remote capabilities of X11 proved extremely useful during a time when "super" computers would handle the heavy lifting for several users on separate workstations, sometimes over remote networks. Throughout its almost 40 years of use, X11 has been expanded to include modern features, such as the Shared Memory Extension (MIT-SHM), which significantly improves its performance.

Even today, X11 remains widely deployed across Unix-like systems and server environments, and is still available as a fallback on most modern desktop Linux distributions even as newer display protocols like Wayland grow in popularity. This is because server admins can expect X11 to be configurable on both the client and server machines with little to no additional work.

What are X Clients and X Servers?

The X Window System uses a client-server model consisting of X servers and X clients:

• An X server is a program on a machine which manages access to graphical displays and input devices (e.g., monitors, mice, keyboards).
• An X client is a program which handles graphical data (e.g., GUI applications, terminal emulators, window managers).

In this model, an X client application can form a connection to an X server to communicate with the X server's devices through graphical primitives. The important thing to remember is that in most scenarios, an X server runs on the user's machine, while an X client runs on the remote machine.

X11 was designed to be network transparent, so that X servers and X clients can communicate over local and remote networks in the same way. This is done by linking an X server to an exposed tcp address rather than the default localhost or unix socket.

However, X11 is an insecure plaintext protocol by default, and it is not recommended to expose an X server directly. Instead, many users who rely on X11 today use X11 forwarding to take advantage of SSH’s encryption and authentication when running graphical apps remotely, especially in HPC, EDA, and financial services environments.

What is an X Display?

In the X Window System, a display refers to a group of display devices to which an X server can send graphical data to and from. An X display is generally made up of at least one screen, keyboard, and pointer device.

In this context, a screen is not a physical monitor, but rather a virtual canvas that can read raw graphical data. In practice, a single screen can be made up of multiple monitors and other virtual displays.

X client programs use the $DISPLAY variable, which looks like hostname:display_number.screen_number, to determine which X display to connect to. An X program can derive a tcp or unix socket from this value to form a connection to the display through the X server. Once the connection is accepted, the X server forwards the connection to the requested screen.

The $DISPLAY variable has two hidden rules that can be a bit confusing.

First: The display number must always be explicitly set, while the hostname and screen number will default to device_name/unix and 0 respectively. As a result, :0 is actually device_name/unix:0.0, and the two values will be treated identically. You can also use unix:0 to refer to device_name/unix:0.

Second: A display's associated tcp or unix socket is derived like so:

• hostname:n -> localhost:6000+n
• hostname/unix:n -> /tmp/.X11-unix/Xn

How is X11 Secured?

There are a few ways that an X server can secure or control access to its displays.

The most common one (and the only one relevant to X11 forwarding) is cookie-based access using the protocol MIT-MAGIC-COOKIE-1. In this protocol, an X client must provide a valid plaintext 32-byte cookie. If the X server recognizes the cookie for the requested display, it will provide the client with access to the display with the set of permissions allowed for that cookie.

These permissions are not fine-grained, and are split into two categories:

• Trusted cookies, which grant full access.
• Untrusted cookies, which restrict access (e.g., confining a program to its own window or blocking clipboard access).

Using the xauth program, you can add and generate cookies in an X server and save them to disk to $XAUTHORITY if set, or ~/.Xauthority otherwise. When running an X program, it will retrieve X authentication data for the requested display from $XAUTHORITY or ~/.Xauthority. This data is used to authenticate when connecting to the X server.

It is important to note that if an X program cannot find any authentication data for the requested display, it will form the connection without the data. The X server will accept the connection regardless and use its default insecure connection method.

This means that it is the sole responsibility of the X program to enforce its own authentication and authorization, rather than the X server enforcing it. For this reason, xauth is usually used alongside other access control systems, such as xhost, to prevent untrusted X clients from even attempting to connect to the X server.

How Does an X Program Work?

Now that each component of X11 has been explained, we can examine what an X program like xeyes looks like in action. As illustrated in the above diagram:

1. The user starts X program xeyes.
2. X program retrieves X authentication protocol and token for unix:0.
3. X program connects to the unix/tcp socket matching unix:0 and requests access to screen 0.
4. X server authenticates the data and forwards the connection to screen 0.

How Does X11 Forwarding Work?

With the basics of X11 out of the way, we can dig into the details of how X11 forwarding works.

X11 forwarding follows the same model as X11, but the X client to X server connection is tunneled through an SSH channel. In order to achieve this flow, the SSH server proxies the remote X client connection to the SSH client, and the SSH client proxies it to the user's X server.

This sounds straightforward enough. However, the SSH server and client do a lot of work behind the scenes to make sure an arbitrary X program in an SSH session gets successfully and securely forwarded to your local X server.

To uncover these secrets of X11 forwarding, we will examine:

1. How to go from ssh -X to a fully configured X11 forwarding SSH session.
2. How an X client program runs in an X11 forwarding session.
3. How X11 forwarding utilizes the local and remote X authorities to prevent anyone on the remote host from accessing a local X server.
4. How untrusted X11 forwarding (ssh -X) differs from trusted X11 forwarding (ssh -Y) when protecting local X servers from malicious remote users and hackers.
5. Best practices and final recommendations for securing X11 forwarding sessions.

Configuring an X11 Forwarding SSH Session

When you enter the command ssh -X remote-user@remote-host, your machine will start up a new SSH client and request an SSH session from the remote SSH server remote-host — the same way it would if you omitted the -X flag.

Once the normal SSH session is created, your SSH client will follow it up with an x11-req SSH request. If X11 forwarding is allowed by the SSH server for the remote-user, then it will begin setting up X11 forwarding for the session.

The SSH server will open up an X server proxy listener starting from localhost:6010 and set the SSH session's $DISPLAY to the corresponding socket localhost:10.

As a result, any X programs started within the session will look at $DISPLAY and connect to the X server proxy's tcp socket. The SSH server will now intercept the X11 connection and forward it to the SSH client.

Once the server signals to your SSH client that X11 forwarding has been successfully configured, the SSH client will send a pty-req SSH request to start a new bash session on the remote host, finalizing the SSH session setup as normal.

Running an X Program in an X11 Forwarding session

With a running X11 forwarding SSH session, we can see what happens when you run an X program like xeyes.

Since the remote bash session has $DISPLAY=localhost:10 set, xeyes will connect to the X server proxy on localhost:6010. When the SSH server receives this connection, it will create an x11 SSH channel for the session and start forwarding the xeyes connection into the channel to the SSH client.

The SSH client will then connect to your local $DISPLAY and forward the xeyes connection from the X11 SSH channel through this connection. The X server will forward this connection to the correct screen and its assigned display devices, thus completing the connection from the remote xeyes program to your local display and I/O devices.

Configuring X11 Forwarding with X Authority

As alluded to above, our X11 forwarding setup is missing a crucial piece of the puzzle.

In its current state, the X11 forwarding session will provide anyone that can access the X server proxy at localhost:6010 on the remote host with access to your local X server. A malicious user on the remote machine could use this to forward an X program that could take screenshots of your display, capture your mouse and keyboard actions, or even inject X11 actions to run its own commands in an open terminal.

To prevent this, we need to provide the SSH client with a way to authenticate requests that come from the remote X server proxy.

To authenticate forwarded X program connections, the SSH client will attach an X authority protocol and cookie to the original x11-req. The cookie will not actually be used to connect to your X server, so the SSH client can generate a random fake cookie for the MIT-MAGIC-COOKIE-1 protocol and keep a record of it before sending it in the request.

Upon receiving the fake X authentication data, the SSH server will add it to the remote X authority at ~/.Xauthority for $DISPLAY=localhost:10.

This time when you run the xeyes program, it will retrieve the fake X authentication data from ~/.Xauthority and attach it to the X server connection.

After tunneling the connection through the X11 channel, the SSH client will read the X auth data from the initial X11 data in the connection, and decide whether or not to accept the connection.

If accepted, the SSH client will retrieve real X authentication data from your local $XAUTHORITY to replace the fake X authentication data in the connection. Finally, the SSH client will forward the connection to your $DISPLAY like before.

What is Trusted X11 Forwarding (ssh -Y)?

Trusted X11 forwarding ssh -Y forwards X11 connections using trusted cookies, giving remote X “trusted” clients full access to your local X server.

This name derives from the fact that, ultimately, you are trusting the access controls of the remote host to protect access to the X server proxy. This means that if someone obtains access to remote-user or root, they can access /users/remote-user/.Xauthority and use it to run X programs connected to your local X server — thus exposing the server to the X11 threats mentioned before.

This is the X authority configuration we’ve explained so far. To protect your X server properly, you will want to use “untrusted” X11 forwarding.

What is Untrusted X11 Forwarding (ssh -X)?

Untrusted X11 forwarding ssh -X forwards X11 connections using untrusted cookies, allowing remote GUI apps to display while restricting risky capabilities like inspecting other windows, grabbing input, or abusing the clipboard.

On the local machine, the SSH client creates a new temporary $XAUTHORITY and uses xauth to create a new untrusted cookie. Now, when the SSH client reads the fake X authentication data from a forwarded X11 connection, it will replace it with this untrusted cookie — rather than using the default trusted settings.

Anyone who connects to localhost:6010 and shows the correct fake X authentication data will only be granted untrusted access. While malicious users could still run an X program and forward it to your X server, any potentially damaging X11 permissions will be restricted.

This is far from a perfect system. In practice, some legacy or complex GUI applications will fail or behave incorrectly because they depend on X11 operations that are blocked for untrusted clients. However, untrusted X11 forwarding can help prevent the more serious risks associated with trusted X11 forwarding.

Is X11 Forwarding Secure?

X11 forwarding over SSH encrypts network traffic and authenticates the remote host, which is a major improvement over running X directly over the network. However, the underlying X11 security model can still give access to local displays once a client is authorized.

In trusted mode, a remote X client can usually:

• Capture keystrokes and mouse events;
• Inspect or manipulate other application windows;
• Read from or write to the clipboard and selections.

Untrusted X11 forwarding reduces these risks by limiting what remote X clients can do, but it does not remove all possible attacks. In particular, any vulnerabilities in your local X server or X extensions can still be exposed to remote programs that you run via X11 forwarding.

Because X11 was not designed for high-latency or zero-trust environments, it is best to treat X11 forwarding as a powerful but risky tool that should be carefully limited, monitored, and eventually replaced with safer alternatives where possible.

Best Practices for Secure X11 Forwarding

Because the untrusted permissions were added as a plugin after the fact — rather than being built into the X11 protocol itself — trusted X11 forwarding is typically the default behavior of ssh -X.

Therefore, it is considered best practice to explicitly set ForwardX11Trusted no in your SSH client config ~/.ssh/config to begin untrusted forwarding. You will still be able to use ssh -Y to override this and request trusted forwarding if you need it for a specific use case.

For sensitive environments, consider combining X11 forwarding with strong authentication, just-in-time access, and auditing where possible. Identity-aware access tools like Teleport can help provide safer alternatives to raw X11 forwarding while revealing instances of insecure SSH access across your environment.

Conclusion

X11 forwarding is a useful and reliable tool for running graphical programs on remote machines securely. It's also relatively easy to set up, making it invaluable for scaling remote graphical access across wide and varied server fleets.

For high-value environments, consider combining X11 forwarding with stronger identity, authorization, and auditing controls or replacing it entirely with more modern, identity-aware access patterns like Teleport.

To stay up to date with Teleport's latest developments, keep an eye on our GitHub page.