Home --> IAQ -->

SSH X-Windows Tunneling Fails

By Jeffrey Howard
All rights reserved unless noted otherwise

Using ssh, you try to run a program with an X-Windows interface. Instead of seeing the window pop up, you see the following error:

channel 3: istate 4 != open
channel 3: ostate 64 != open
Error: Couldn't find per display information

Platform

I ran into this on a Redhat 6.1 machine using OpenSSH version 2.1.

Solution

Notice in the /etc/hosts file printed below that the hostname "magian" shows up as an alias for 127.0.0.1 rather than as an alias for 192.168.123.5.

127.0.0.1       localhost.localdomain   localhost magian
192.168.123.5	magian.burningvoid.com

Check your own /etc/hosts file and see if the hostname is listed similarly. To fix the problem, move the hostname entry to refer to the IP address of an external interface.

127.0.0.1       localhost.localdomain   localhost       
192.168.123.5	magian.burningvoid.com  magian

Now try again. Hopefully, this will fix the problem.

Notes

The reasoning behind this fix is as follows. SSH works by setting the DISPLAY variable to point to "hostname:n.m". In the previous quotation, hostname is the name of the host you're logged in to, n is a number (probably 11) and m is another number (probably 0). When you run a program with an X-Windows interface, it reads the DISPLAY variable and opens a network connection to the machine specified in the DISPLAY variable.

When using SSH, that means that the program is opening a connection to the same machine that you're running the program on. This is entirely the right thing to do because SSH is listening for that connection. When SSH gets that connection, it tunnels all the information back to your local machine, where the local copy of SSH connects to your X server and displays the interface to you.

So what's going wrong? Well, X uses the hostname in the DISPLAY variable to look up the address to which to send display information. That hostname is resolved by /etc/hosts. If the hostname resolves to the IP address of some external interface, everything works great. X opens a TCP/IP connection to SSH that gets tunneled correctly. If, however, the hostname resolves to a loopback address (anything inside the 127.0.0.0 network, such as 127.0.0.1), then X is too smart for SSH's own good. X will try to skip using TCP/IP for loopback addresses in favor of a more efficient means of interprocess communication. This other method of IPC is not expected by SSH, so the two programs fail to connect.

The solution is to make sure X is forced to use a non-loopback IP address. This is easily done by modifying the /etc/hosts file as described above.