Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have read in a few websites e.g. (1) that the default ssh cipher is not necessarily the fastest.

I work on a local fully secure network. Assuming that security is not an issue and that I just care about latency and speed, what ssh parameters can a user tune to get the fastest X tunneling?

share|improve this question
up vote 6 down vote accepted

If you're on a secure network, why encrypt? You can directly X forward without ssh, and get better speed and latency.

See for example this (old but still valid) tutorial; here you could use the (insecure) Xhost mechanism:

A Little Theory

The magic word is DISPLAY. In the X window system, a display consists (simplified) of a keyboard, a mouse and a screen. A display is managed by a server program, known as an X server. The server serves displaying capabilities to other programs that connect to it.

A display is indicated with a name, for instance:


The display consists of a hostname (such as light.uni.verse and localhost), a colon (:), and a sequence number (such as 0 and 4). The hostname of the display is the name of the computer where the X server runs. An omitted hostname means the local host. The sequence number is usually 0 -- it can be varied if there are multiple displays connected to one computer.

If you ever come across a display indication with an extra .n attached to it, that's the screen number. A display can actually have multiple screens. Usually there's only one screen though, with number n=0, so that's the default.

Other forms of DISPLAY exist, but the above will do for our purposes.

Telling the client

The client program (for instance, your graphics application) knows which display to connect to by inspecting the DISPLAY environment variable.

Our computer is known to the outside as light, and we're in domain uni.verse. If we're running a normal X server, the display is known as light.uni.verse:0. We want to run the drawing program xfig on a remote computer, called dark.matt.er, and display its output here on light.

Suppose you have already telnet/rsh/ssh-ed into the remote computer, dark.matt.er.

If you have sh running on the remote computer:

dark$ DISPLAY=light.uni.verse:0
dark$ export DISPLAY
dark$ xfig &

or, alternatively:

 dark$ DISPLAY=light.uni.verse:0 xfig &

Telling the Server

The server will not accept connections from just anywhere. You don't want everyone to be able to display windows on your screen. Or read what you type -- remember that your keyboard is part of your display!

Too few people seem to realise that allowing access to your display poses a security risk. Someone with access to your display can read and write your screens, read your keystrokes, and read your mouse actions.

Most servers know two ways of authenticating connections to it: the host list mechanism (xhost) and the magic cookie mechanism (xauth). Then there is ssh, the secure shell, that can forward X connections.

Notice that some X servers can be configured not to listen on the usual TCP port with the -nolisten tcp argument. Notably the default configuration of Debian GNU/Linux is to disable the X server listening on the TCP port. If you wish to use remote X on a Debian system, you should re-enable this by altering the way the X server is started. Look at /etc/X11/xinit/xserverrc for a start.


Xhost allows access based on hostnames. The server maintains a list of hosts which are allowed to connect to it. It can also disable host checking entirely. Beware: this means no checks are done, so every host may connect!

You can control the server's host list with the xhost program. To use this mechanism in the previous example, do:

 light$ xhost +dark.matt.er

This allows all connections from host dark.matt.er. As soon as your X client has made its connection and displays a window, for safety, revoke permissions for more connections with:

 light$ xhost -dark.matt.er

You can disable host checking with:

 light$ xhost +

This disables host access checking and thus allows everyone to connect. You should never do this on a network on which you don't trust all users (such as Internet). You can re-enable host checking with:

 light$ xhost -

xhost - by itself does not remove all hosts from the access list (that would be quite useless - you wouldn't be able to connect from anywhere, not even your local host).

Xhost is a very insecure mechanism. It does not distinguish between different users on the remote host. Also, hostnames (addresses actually) can be spoofed. This is bad if you're on an untrusted network (for instance already with dialup PPP access to Internet).

share|improve this answer

"blowfish" is the fastest available according to the man page for proto 1, and for proto 2 there are:


I believe blowfish-cbc would be the fastest among all of them, but actually it needs testing.

Obviously you hardly need Compression.

There's also IPQoS option which by default is “lowdelay” for interactive sessions and “throughput” for non-interactive sessions.

share|improve this answer
Thanks! What about the -Y option. Would that have any impact at all? – Amelio Vazquez-Reina Oct 11 '12 at 23:53
@user27915816, no, I don't think that -Y impacts. – poige Oct 12 '12 at 5:32
Yup, this agrees with my findings: security.stackexchange.com/questions/12901/… – Marcin Oct 12 '12 at 12:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.