How to speed up X11 forwarding in SSH

When you are running X applications over SSH, the encryption/decryption overhead of the SSH protocol may slow down the rendering of remotely running X applications. Furthermore, if an SSH session is established over a wide area network, X11 forwarding over SSH may become even slower due to network latency and throughput limitation.

In this tutorial, I will describe some tips on how to speed up X11 forwarding in SSH over wide area networks.

There are two ways to boost the performance of X11 forwarding via SSH.

First, you can use the compression option of OpenSSH client. With "-C" option, OpenSSH client will compress all data exchanged over SSH, including stdin, stdout, stderr and forwarded X11 sessions.

You can also consider using less computation-heavy ciphers in SSH, so that less time is spent during encryption/decryption. The default AES cipher used by OpenSSH is known to be slow.

An independent study shows that arcfour and blowfish ciphers are faster than AES, as shown below. According to SSH man page, blowfish is a fast block cipher which is also very secure. Meanwhile, arcfour stream cipher is known to be more vulnerable than common block ciphers. So use caution when using arcfour.

To speed up X11 forwarding by using the above tips, you can SSH to a remote host as follows.

$ ssh -XC -c blowfish-cbc,arcfour

Alternatively, you can specify these options in a SSH configuration file.

To edit a system-wide SSH configuration file:

$ sudo vi /etc/ssh/ssh_config

To edit a per-user SSH configuration file:

$ vi ~/.ssh/config

In either SSH configuration file, add the following:

  Compression yes
  ForwardX11 yes
  Ciphers blowfish-cbc,arcfour

Then you can SSH to the remote host without using any command-line option:

$ ssh

Note that there are some caveats in switching to a different cipher in SSH. First, the performance of a particular cipher may vary across different processor architecture. For instance, recent generations of Intel processors (e.g., Intel i5, i7, Xeon) come with hardware support for AES (e.g., AES-NI), in which case (hardware-accelerated) AES would be much faster than the rest.

Second, if the network over which X11 forwarding is established is extremely slow, then the bottleneck of X11 forwarding is actually the network, not the CPU. In this case, the performance of X11 forwarding would not be affected whichever cipher you are using.

Subscribe to Xmodulo

Do you want to receive Linux FAQs, detailed tutorials and tips published at Xmodulo? Enter your email address below, and we will deliver our Linux posts straight to your email box, for free. Delivery powered by Google Feedburner.

The following two tabs change content below.
Dan Nanni is the founder and also a regular contributor of He is a Linux/FOSS enthusiast who loves to get his hands dirty with his Linux box. He likes to procrastinate when he is supposed to be busy and productive. When he is otherwise free, he likes to watch movies and shop for the coolest gadgets.

10 thoughts on “How to speed up X11 forwarding in SSH

  1. Nice. They forgot the old standby though. Greyscale! Takes a lot less data to send greyscale thru than it does full color...

  2. You can have even less typing if you put the username for the connection profile and an alias for the host in your .ssh/config file.

  3. Do not do X11 forwarding in the first place. It is bad, just bad.
    1) X is NOT network transparent
    2) Sending pixbuffs over the network eats up bandwidth

    Just don't do it !

    • There are times when it's necessary and/or useful.

      X11 is designed as a network-capable protocol.

      There are some applications (generally proprietary crap) which must be run on servers and which require X11. Oracle's installer comes to mind (it may have changed, but last I checked still ran as an X client).


        The article I referenced is written/fact checked by X developers. They say X is NOT network transparent.

        " II) “X is Network Transparent.” Wrong. Its not. Core X and DRI-1 were network transparent. No one uses either one. Shared-Memory, DRI-2 and DRI-3000 are NOT network transparent, they do NOT work over the network. Modern day X comes down to synchronous, poorly done VNC. If it was poorly done, async, VNC then maybe we could make it work. But its not. Xlib is synchronous (and the movement to XCB is a slow one) which makes networking a NIGHTMARE."

        • I didn't say network transparent. I said network-capable.

          And oddly enough: if I run X clients forwarded over SSH connections ... they work. Mostly. Enough that it's useful.

          You can give me all the technical justifications and language-lawyering you want. The point is that it's practical, it's possible, and I've been doing it for nearly 20 years.

  4. Unless your wide-area network is EXTREMELY slow, I usually recommend AGAINST using compression. The latency added by the zlib compression step nearly always seems to end up being a net loss. The only time I personally have ever found the compression to be beneficial is with a very slow network combined with very fast CPUs.

  5. Terrible article. It advocates system-level config changes to use weaker ciphers without providing much in the way of evidence to support it. In particular it doesn't provide any real evidence that "the encryption/decryption overhead of the SSH protocol may slow down the rendering of remotely running X applications", which is the opening claim.

    It also doesn't take into account the effects of latency, only bandwidth. Latency and round trip times are probably the number one reason why remote X is terrible and anyone with sense uses something like VNC instead.

    Modern Intel CPUs have hardware support for AES, so I'm curious as to whether that was being used here. If it wasn't... well, this might not even gain you anything at all. That's if this "overhead" makes any difference anyway, which I doubt.

  6. X11 is not secure. Remember X11 forwarding opens up pandora box. The nightmare of X11 is that there is no clear definition of client/server roles. So unless you are very particular in setting up xnest or other X11 isolation, the X11 server you connect to at the other end of an SSH tunnel can control all applications your end.

    Encrypted RDP/VNC/NX/SPICE. Number 1: these do have clear separation by default, so remote end cannot control client end directly. Number 2: these normally use compression. Number 3: even sending over ssh you gain compared to X11.

    Edward Morbius: 20 years ago, system to system attacks did not happen.

    Yes there are reasons why we need wayland protocol and the new solutions on top for remote users. With X11, there are tons of security write ups telling everyone to stop using it.

    Yes we still have too many people saying we used it for 20+ years it is fine. That is like saying 20 year old car tyres will perform like new ones. They will not.

  7. I live in the boonies with a very slow DSL connection, my maximum connection speed is about 1.1 Mbps.

    At work I have some fairly intensive graphical waveform X applications (similar to multi channel oscilloscopes) that I run on a linux machine. I wanted to be able to connect to the work machine from home and run the graphical X apps remotely.

    The machine at work is located behind a firewall login server so I cannot use a direct connection from my home machine to my work machine.

    To make this work I create a port forwarded ssh tunnel from the home linux machine through the firewall login server to my work linux machine. I have NX setup on the home and work machines. I then use NX over the port forwarded ssh connection and can then run the X apps. This method works surprisingly well. I have tried running the X apps directly over SSH (without NX) but it does not work at all.

    I remember reading a few years ago that the X developers were considering putting NX technology directly into X, that would have been really good.

    I've been using this method now for several years, is there anything else out there I should try?

Leave a comment

Your email address will not be published. Required fields are marked *

Current ye@r *