As I described in an earlier post, I run my Raspberry Pi (RPi) as a headless system, using Cygwin/X‘s xterm for command line interaction with the RPi, with my PC being my X server to support any X Window applications. I can move files between the PC and the RPi via my pseudo-Dropbox. I really recommend this configuration and its working perfectly for me.
This configuration gives me a great deal of utility but no mobility …. I’m still tied to my desktop PC. Maybe I should consider replacing the desktop PC with a laptop but I don’t want to spend the money. I have seen some small, inexpensive keyboards and displays that could be connected directly to the RPi, and you could cobble together a mobile unit, or the more elegant Kindle version, but this still doesn’t give me the mobility look & feel I would like.
iPad to the rescue (assuming you have one ….)! I found a great app call iSSH by Zingersoft. Its claims that it is a “comprehensive VT100, VT102, VT220, ANSI, xterm, and xterm-color terminal emulator over SSH and telnet, integrated with a tunneled X server, RDP and VNC client. ” I installed it, configured it quickly, and got a terminal connection to the RPi without reading the documentation …. Impressive since successfully configuring ssh, Xserver, etc. can be challenging sometimes. (Note: The easy of this was largely due to setting up RPi environment properly in the first place. See the earlier post). To top it off, iSSH has a slick look & feel.
Zingersoft’s documentation on configuring iSSH is easy to follow and requires just a few steps. I had no problem getting an terminal session working to the RPi but I did have problems with graphics programs (i.e. X Window client programs). It appears that iSSH’s terminal isn’t really xterm but a terminal emulation (secured via ssh). The iSSH terminal doesn’t use the X server. In fact, while in the terminal session, to see the X server display (i.e. to see graphics applications rendered via the RPi X client) you must hit the button at the top right of the iPad display.
Frankly, the fact that the X application didn’t work the first time wasn’t a big surprise to me. I have been struggling with getting my X Window configuration set up to work reliably for some time. What I was observing was that X would work fine for sometime but at some point I would get the error message “couldn’t connect to display”.
This error is very common and nearly every X user has seen some version of this before. I assume that the right way to solve this was to gain a deeper understanding of X Windows and discover its root cause . I did gain a deeper understanding of X Windows, but a solution to my problem never jumped out from the “official” materials I read. I found the solution when I happened upon the blog “X11 Display Forwarding Fails After Some Time“.
The root cause of my error message is the time out of the X Forwarding. I have been using the -X option when using ssh. This is the more secure option for X Forwarding, but comes at a price, as shown below.
ssh -X, X forwarding is enabled in “Untrusted” mode, making use of various X security extensions, including a time-limited Xauth cookie.
ssh -Yto enable “Trusted” mode for X, which will enable complete access to your X server. There is no timeout for this option.
So my Display problem isn’t really an error, per say, but ssh timing out on me. To fix this, I added the entry
ForwardX11Timeout 596h into my
~/.ssh/config file on my PC. With this problem solved, I continued my journey into X.
My Journey to a Better Understanding of X
Using X Windows for the first time can be somewhat of a shock to someone familiar with other graphical environments, such as Microsoft Windows or Mac OS. X was designed from the beginning to be network-centric, and uses a “client-server” model. In the X model, the “X server” runs on the computer that has the keyboard, monitor, and mouse attached. The server’s responsibility includes tasks such as managing the display, handling input from the keyboard and mouse, and other input or output devices (i.e., a “tablet” can be used as an input device, and a video projector can be an output device, etc.). Each X application (such as xterm) is a “client”. A client sends messages to the server requesting things like “Please draw a window at these coordinates”, and the server sends back messages such as “The user just clicked on the OK button”. These standardized set of messages make up the X Protocol.
The X server and the X clients commonly run on the same computer. However, it is perfectly possible to run the X server on a less powerful computer (e.g. in my case a PC or iPad), and run X applications (the clients) on a powerful machine that serves multiple X servers (or it can be a simple RPi, as in my case). In this scenario the communication between the X client and server takes place over the network (WiFi for my iPad), via the X Protocol. There is nothing in the protocol that forces the client and server machines to be running the same operating system, or even to be running on the same type of computer.
It is important to remember that the X server is the is the software program which manages the monitor, keyboard, and pointing device. In the X window system, these three devices are collectively referred to as the “display”. Therefore, the X server serves displaying capabilities, via the display, to other programs, called X clients, that connect to the X server. All these connections are established via the X protocol.
The relationship between the X server and the display are tight, in that the X server is engineered to support a specific display (or set of displays). As a user of X, you don’t have any control over this relationship, only the software developer who created the server can modify this relationship (generally speaking). On the other hand, as a user you have free hand in configuring the X protocol connection between the X server and the X clients.
How do you establish a X Protocol connection between any given server and a client? This is done via the environment variable “DISPLAY”. A Linux environment variable DISPLAY tells all its X clients what display they should use for their windows. Its value is set by default in ordinary circumstances, when you start an X server and run jobs locally. Alternatively, you can specify the display yourself. One reason to do this is when you want log into another system, and run a X client there, and but have the window displayed at your local terminal. That is, the DISPLAY environment variable must point to your local terminal.
So the environment variable “DISPLAY” stores the address for X clients to connect to. These addresses are in the form:
hostnameis the name of the computer where the X server runs. An omitted
hostnamemeans the localhost.
displaynumberis a sequence number (usually 0). It can be varied if there are multiple displays connected to one computer.
screennumberis the screen number. A display can actually have multiple screens. Usually there’s only one screen though where 0 is the default.
Setting the DISPLAY variable depends of your shell, but for the Bourne, Bash or Korn shell, you could do the following to connect with the systems local display:
The remote server knows where it have to redirect the X network traffic via the definition of the DISPLAY environment variable which generally points to an X Display server located on your local computer.
So you see, as the user, you have full control over where you wish to display the X client window. So what prevents you from doing something malicious, like popping up window on someone else terminal or read their key strokes? After all, all you really need is their host name. X servers have three ways of authenticating connections to it: the host list mechanism (xhost) and the magic cookie mechanism (xauth). Then there is ssh, that can forward X connections, providing a protected connection between client and server over a network using a secure tunnelling protocol.
The xhost Command
xhost program is used to add and delete host (computer) names or user names to the list of machines and users that are allowed to make connections to the X server. This provides a rudimentary form of privacy control and security. A typical use is as follows: Let’s call the computer you are sitting at the “local host” and the computer you want to connect to the “remote host”. You first use xhost to specify which computer you want to give permission to connect to the X server of the local host. Then you connect to the remote host using telnet. Next you set the DISPLAY variable on the remote host. You want to set this DISPLAY variable to the local host. Now when you start up a program on the remote host, its GUI will show up on the local host (not on the remote host).
For example, assume the IP address of the local host is 184.108.40.206 and the IP address of the remote host is 220.127.116.11.
On the local host, type the following at the command line:
xhost + 18.104.22.168
Log on to the remote host
On the remote host (through the telnet connection), instruct the remote host to display windows on the local host by typing:
Now when you type xterm on the remote host, you should see an xterm window on the local host. You should remove the remote host from your access control list as follows.
xhost - 22.214.171.124
Some additional xhost commands:
xhost List all the hosts that have access to the X server
xhost + hostname Adds hostname to X server access control list.
xhost - hostname Removes hostname from X server access control list.
xhost + Turns off access control (all remote hosts will have access to X server … generally a bad thing to do)
xhost - Turns access control back on (all remote hosts blocked access to X server)
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 more detail: A Better Mobile Display for the Raspberry Pi