Faster SSH/x11 forwarding w/o installing software on the server
Does anybody know any way to accelerate X11 forwarding on SSH, except for using a faster cypher and compression, without installing any software on the server? In my case I do not have any permission to install software on the server. It belongs to my university. However, I would like GUI programs that run on the server and displayed on my home computer to be actually usable.
Tunneling X11 through ssh is quite bandwidth expensive and the X protocol is not ideal for high RTT links. You may simply not have enough bandwidth, or too much latency, for it to be usable.
You seem to have already narrowed down the options you have:
options needing you to install software on both ends (either an X protocol optimizer such as x2go, FreeNX or others, or using another protocol than X over SSH such as VNC or Remote Desktop)
using compression (or not, it should be better with but try both): option -C
using a less expensive cipher protocol such as BlowFish-CBC or arcfour (the second is less secure): add option -c blowfish-cbc
The only one you seem to have missed is if your X program is Firefox, in which case it seems that setting network.http.pipelining and using ssh multiplexing could make a difference.
I use ssh-hpn, a series of patches to the official SSH code for higher performance, for any time I need high-performance SSH. Some platforms like FreeBSD include it out of the box, on others you can install it via a package manager, or you can compile it from source and add the patches in yourself.
If you're on a popular platform, you can probably find a binary distribution of ssh-hpn (though for obvious security reasons, building from source is always better w/ a piece of software like this).
If you really don't care about security at all, you can use X11 over netcat (aka nc) instead of ssh. It's likely already installed on your machine, too.
Idea #1: Turn compression off. Yes, off. It is possible, that your problem is not about bandwidth, but about latency. Having compression in the channel makes normally very bad latency for GUI applications. If you have a good bandwidth, I would suggest a nice try seeming weird on the first spot: turn off compression everywhere.
Idea #2: Try to use another ssh implementation. Then openssh is a little bit notorious about its speed. Probably its partial reason that its developers are focusing to the security, and speed is a secondary thing for them. The cause of the latency is probably not the slowness of the encryption algorithms, but the inefficient handling of the simultanous data transfer events (in many directions, both of incoming and outgoing), and also the calculation/compression/encryption things in a single-threaded, not event oriented software. (For example: typical working of the software: first it encrypts a data block, then sends it to the network, finally reads what the remote side sent to us, and decrypts it. It seems perfectly okay, but it contains a terrible latency: arrived data blocks won't be read until the actual block compression isn't ready... It be should be implemented on a multithreaded, or at least asyncronsous way, and openssh is very, very, very bad in this).
Idea #3: Check the config on both side. Compression can be set on both of the server and also in the client configuration. It seems to me not unrealistic, that maybe you only set up on one of the sides. Check, really check that it really happens on both side (although probably on the sending side it is not really important, because your mouse movements and keyboard hits aren't use too many bandwidth for that. Maybe an asymmetric solution, also compressing the large image operations on the server->client side, while sending uncompressed, low-latency client->server data promises the best result.