OroborOSX

More than just another window manager!
A complete environment for X11 on Mac OS X

About
OroborOSX

Version
History

Download

|
|

Troubleshooting

E-mail lists
and forums

|
|

Introduction to
X11 on OSX

About
XDarwin

XDarwin
forums

|
|

About
Oroborus

Forwarding X11 from a Remote Computer to the Mac

One of the most useful features of X11 is the ability for the X server (XDarwin on your Mac in this case) to respond not only to local X clients, but also remote X clients.

What this means in practice is that there is little difference between running an X11 program on your Mac (with its windows appearing on your Mac's screen) and running an X11 program on any other machine anywhere in the world (bandwidth permitting) -the remote X11 client's windows can still appear on your Mac as though you are running locally.

Of course, you don't want to allow just anyone to start up X11 clients that connect to your Mac's X server -they could do all sorts of things, like collect your keystrokes and even take snapshots of your screen. That's why only an authorised client should be allowed to connect (and why you should never use the command "xhost +"!)

While on the subject of unauthorised access to your X server, if you do find you suddenly get a window appearing on your X11 desktop that you did not expect (and which looks like it has come from an external source), you can use the "xlsclients" command to list currently connected clients (so you might be able to check where it has come from), and then use the "xkill" command to destroy the window (it will ask you to click on the window you wish to destroy).

At this point it is probably worth making a note about terminology. It is very easy to confuse clients and servers when talking about X11. The basic rule to remember is that XDarwin on your Mac is the X server and any X11 programs you run, whether remotely or actually on your Mac, are known as X clients. This tends to be slightly counterintuitive, because the remote machine is often thought of as the server. However, in the case of X11, only the local machine (i.e. where you are sitting, the screen you are looking at) can be the server because that is where all the clients put their windows.

OK, with that introduction out of the way, we can proceed to ask the vital question...

How do I Authorise my Remote Machine to use my Mac's X Server?

There are three basic ways to do this, listed here in order of preference:

Use "ssh -X";

Use xauth with your DISPLAY environment variable;

Use xhost with your DISPLAY environment variable.

Each of these methods will be outlined below, along with a number of tests that can be used to solve some common problems.

However, as an aside we shall first answer another important question...

What are the advantages and disadvantages of each method listed above?

The only truly secure method of connecting is via ssh (or some other encryption tunnelling software, such as zebedee, or perhaps over a VPN, if you are able to use that with X11).
The other methods (xauth and xhost) only provide authorisation for the remote client to connect to your Mac's X server (i.e. to XDarwin) - all data sent between the X11 client and the X server is completely open (i.e. it can be 'sniffed' by anyone who has access to any networks between the client and server, so they can potentially watch all events sent to that client from your Mac [keystrokes and cursor movement, for example], as well as all screen drawing that is requested by the remote client).

You might wonder, then, why anyone would use anything other than ssh!

The major problem with ssh is that it is noticeably slower under a heavy load. This is because all data sent between client and server has to be encrypted before it can be sent, and then decrypted at the other end. (Note that you can speed things up slightly by using "blowfish" encryption, rather than the default "3des" - see below how to do this.)
However, this is only a valid point if you can shift data from client to server faster than ssh can encrypt/decrypt it! In other words, if you are not connecting over a fast local network, then ssh will not slow you down. (Even a fast DSL connection is enough of a bottleneck that you will not see a difference when using ssh.)
Under most circumstances you will not notice any slowdown -it's only under heavy load that it becomes apparent. For example, I've seen it when trying to view large animations (several megabytes) in a Netscape window (running from an Alpha workstation on the same 100BaseT local network as my Mac).

To summarise, then, ssh should be the primary choice if you can use it (especially if you are connecting outside a local network).

The exception to this is if you are viewing something which requires high-bandwidth (i.e. graphics that change very quickly, or are very large). But if this is the case, then you would not be able to work over even a DSL connection, so you are likely to be within a fast local network (or a very high-bandwidth connection between academic institutions, perhaps) where your TCP packets are not flying around the internet so far and wide that you do not know who might be able to intercept them!

Even if you do need a high-bandwidth connection for some X11 application, it's probably worth stopping for a moment to think about how to minimise other unencrypted X11 data across your connection. -For example, you may want to only start that particular X11 application with an unencrypted connection, but use ssh for your remote terminals (xterms, say) and editors (nedit/xemacs, for example) - such things do not need such a fast connection, so it's well worth keeping them secure. (Thanks to Patrik for that idea!)

Let's take a look in more detail at how to actually use each method...

Use "ssh -X"
This is by far the easiest method because ssh does everything for you! As long as the remote machine is running an ssh daemon, all you have to do is type:
```
ssh -X <remote-username>@<remote-machine>
```
It will then ask you for your password on the remote machine. As long as your DISPLAY variable was set correctly before you typed the command (see below), it should all work without any problems.
Handy Hints...
- If your remote username is the same as your local username then you don't need to include it in the ssh command. i.e. you can just type:
```
ssh -X <remote-machine>
```
- If you are not connecting through a local network (LAN), it's well worth switching on ssh compression (-even broadband connections will probably benefit from this). You can do this using the "-C" option:
```
ssh -C -X -c blowfish <remote-username>@<remote-machine>
```
  (I've also changed the encryption to blowfish, which is somewhat faster than the standard 3des encryption used by ssh -it's also considered to be potentially more secure.)
- With all these extra options, typing it in every time can become a bit of a pain - which is why I have set up an alias in my .login file. This is simply a single line which defines the command ssx to mean "ssh -C -X -c blowfish":
```
alias ssx ssh -C -X -c blowfish
```
  So now all I have to do is type:
```
ssx <remote-username>@<remote-machine>
```
How to diagnose problems when using "ssh -X"
- Before you type "ssh -X", make sure that your DISPLAY variable is set up. You can do this by typing:
```
echo $DISPLAY
```
  It should respond with something like ":0.0" (this assumes that your display number in XDarwin's prefs is set to zero - if it is set to one, for example, then DISPLAY will be something like ":1.0"). If it returns an error that DISPLAY is undefined, or if it shows something completely different, then you will need to
  edit your shell init files to make sure DISPLAY is set correctly.
  If, after seeing what it says in response to the above command, you are in any doubt that your DISPLAY is correct, try typing this:
```
xterm
```
  If you see an xterm window appear then all is well - you can close it and continue with the "ssh -X" command to connect to the remote host. Then you can carry on to the next diagnostic test. (If you get an error that the xterm command cannot be found, make sure you have set up your PATH correctly.)
- Once you have connected to the remote host, you should check what DISPLAY is set to at the remote end:
```
echo $DISPLAY
```
  It should respond with something like "localhost:10.0", or "<remote-machine>:10.0". Note that the DISPLAY is not pointing back to your Mac! The remote machine should be pointing to itself, and the display number should be something like "10" or higher. (The actual number it uses will depend on other X11 connections that are already open on the remote machine - the ssh forwarding normally starts at ten, increasing if it finds that display number is already in use, until it finds one that is available.)
  If the response you get is that DISPLAY is undefined, then it probably means that your remote host's ssh server does not have X11 forwarding switched on. You can check this by looking in the sshd configuration file (usually "/etc/sshd_config") on the remote host for a line that says:
```
X11Forwarding yes
```
  If you do not see this line, or if it says "no" instead of "yes", then you will have to edit the config file and restart the sshd server. (If you do not have administrator/root access to the remote machine then you will have to ask someone who has to do it for you.)
  (Note: if the line starts with a hash character "#", that means it is 'commented out' - just remove the hash and restart sshd.)
  However, if the response you get from "echo $DISPLAY" is something like ":0.0", or "localhost:0.0", or "<remote-machine>:0.0", then it most likely means that one (or more) of your shell init scripts on the remote host contains something which tries to set DISPLAY for you. -Check through your shell init scripts (.tcshrc, .cshrc, & .login if you are using tcsh or csh, or .profile [and .bashrc, etc.] if you are using sh, zsh, ksh, bash, etc.)
Once your DISPLAY looks like it is set up OK at both ends, you should be able to connect without any trouble.

If the remote machine is not running ssh then use "xauth" and the DISPLAY variable
Using xauth requires that your X server is given a "MAGIC-COOKIE" which it will use to authenticate any connecting clients.
These Magic-Cookies are normally stored in a file called .Xauthority in your home directory (though the location is overridden by the XAUTHORITY environment variable), which must be readable only by yourself (otherwise it's possible for other users on your system to see the contents and read your Magic-Cookies).
Here are the steps to use:
- Generate a Magic Cookie on your Mac
  Versions of OroborOSX from 0.8.5 onwards attempt to create an entry in your .Xauthority file when they start up their private version of XDarwin. (It uses the "openssl md5" command to do this, so it will fail if it cannot find this command - check the console log to be sure, since it reports a warning if it fails.) -So you should be able to move on to the next step (finding your Magic-Cookie) if you are starting your X server through OroborOSX (from v0.8.5).
  If you are starting XDarwin yourself then you must create your own entry in the .Xauthority file and tell XDarwin to use it when it starts. You can do this as follows (this assumes you are using display number zero, that you have at least OSX10.1 for /dev/random, and that you either do not have your XAUTHORITY variable defined, or that it points to .Xauthority in your home directory) - please note the backquotes that surround the commands after the dot in the first line:
```
xauth add :0 . `more /dev/random | head -10 | openssl md5`
startx -- -quartz -auth ~/.Xauthority
```
  If you do not have /dev/random (i.e. if you have OSX10.0) then you must supply some 'randomish' text for the md5 command to use. This can often be easily accomplished by something like the "ps" command. So, instead of generating your Magic-Cookie from /dev/random, try this (and note those backquotes again):
```
xauth add :0 . `ps auxww | openssl md5`
```
  Of course, you could make up your own Magic-Cookie - it's only a long hexadecimal number (with an even number of digits). For example, here's how to use the xauth command with a completely made up Magic-Cookie:
```
xauth add :0 . ab12cd34ef56fe78dc90ba1a2b3c4d5e6f
```
  It's obviously a good idea to make sure your cookie is not too simple, nor too short. (If you just type "ps auxww | openssl md5" you will see a typical example of a hexadecimal number that can be used as a Magic-Cookie.)
  If you already have XDarwin running, it is still possible to ask it to generate a Magic-Cookie for you (thanks to Richard for pointing this out!) - the advantage here is that you can avoid using "openssl md5" to create that Magic-Cookie. Note the dot at the end of this line:
```
xauth generate :0 .
```
- Find your Magic Cookie
  Once you have an X server running with a Magic-Cookie entry in the appropriate xauthority file, you can begin to use it to authorise remote machines to connect.
  What you need to do is to find out your Magic-Cookie on your Mac:
```
xauth list :0
```
  This will return a line which looks something like this:
```
localhost/unix:0  MIT-MAGIC-COOKIE-1 b3942f4becd56efb9d7889cc6ff6b1c9
```
  The Magic-Cookie is the long string of hexadecimal digits (from "0" to "f") at the end of the line. In the example above it is b3942f4becd56efb9d7889cc6ff6b1c9.
- Set DISPLAY on the remote machine
  Once you have a command-line on the remote machine, you need to set up the DISPLAY variable to point back to your Mac (again, I'm assuming you have started XDarwin on display number zero here, and that you are using csh/tcsh - if you are using sh/zsh/ksh/bash then change "setenv DISPLAY ..." to "DISPLAY=...", and also type the command "export DISPLAY" to make sure it is exported to any other processes you start):
```
setenv DISPLAY <Mac's-name-or-IP-address>:0
```
  At this point if you try to start up any X11 clients from the remote machine you will find it cannot connect - this is because it is not yet authorised.
- Authorise the remote machine by adding an xauth entry
  To authorise the remote machine to connect you must add the Magic-Cookie into your remote xauthority file. So type the following at the command-line on the remote machine:
```
xauth add $DISPLAY . <Mac's-MAGIC-COOKIE>
```
  Having done all of the above, you should now be able to start X11 clients without any problems.
  Of course, to get your Mac's Magic-Cookie onto that line you would have to paste it there (or type it in by hand). Unfortunately, this has its own security problems, as we shall see in a moment...
- Unauthorise the remote machine by removing the xauth entry
  Once you have finished using the remote machine to run X11 clients, you might want to ensure that nobody else who might get access to your remote user account can go even further and actually access your Mac's X server.
  You can do this simply by removing the Magic-Cookie from your xauthority file as follows (type this on the remote machine before you log out):
```
xauth remove <Mac's-name-or-IP-address>:0
```
Security problem when sending your Magic-Cookie to the remote machine
If you are using ssh then there is really no problem with typing anything at the command-line on the remote host - it is all encrypted while in transit from your Mac to the remote machine (and vice versa).
However, if an ssh server is available on the remote machine then you would not be using xauth would you?! (You would be able to use the much more secure "ssh -X", as instructed above.)
Unless you are using ssh (or some other form of encryption tunnel) then you are most likely typing 'in the clear' from your Mac to the remote machine. What this means is that everything you type (or paste) can be 'snooped' by anyone who may have the ability to watch TCP packets on any network that lies between your Mac and the remote machine - this includes your Magic-Cookie that you just typed/pasted into the above 'xauth add' command...
I guess there are some possible ways around this - for example, you could create a file containing your Magic-Cookie, then encrypt it somehow and send it to your remote machine, where you would then unencrypt it and use it in the "xauth add" command (but you must be sure not to look at the unencrypted file on the remote machine since that would mean the text of the file is sent back through the link to be shown on your Mac).
However, it's probably not worthwhile trying so hard to be secure since you are already quite insecure simply by logging in to the remote machine with a non-encrypted tunnel. (For example, if you used telnet to connect, then you have just typed your password to get into the remote machine - and that password was sent in plain view all the way through the link from your Mac to the remote host - so I don't know why you would be worried about someone seeing your X server's temporary Magic-Cookie [it changes each time you start XDarwin] when your password is just as vulnerable and probably remains the same over many many connections...)
I guess the moral of the above is simply this: if the remote machine is not running an ssh server (or some other encryption protocol you can use), ask the system administrator why not!?
How to diagnose problems when using xauth (or xhost)
There are several things to look out for when using xauth (-the first and last of these also apply if you are diagnosing problems with xhost, and the point about checking DISPLAY in the second is also relevant):
- First of all, make sure that you can see your Mac from the remote machine:
```
ping <Mac's-name-or-IP-address>
```
  The ping command sends some data to the specified address, reporting whether or not it receives a response. (You may need to type control-C to stop it sending after a few lines.)
  If you cannot get through to your Mac from the remote machine then it's possible your Mac is on a private NAT-based network. (It's also possible there could be a firewall between the two machines which blocks ping packets, but that is not so common - try accessing your Mac with some other protocol, like ssh [switch on remote login in your Mac's sharing panel].) If your IP address is in the range 192.168.x.x, 172.16.x.x or 10.x.x.x, then you are probably on a NAT-based network and will not be able to get through (unless the remote machine is also on the same network) - as far as I know, ssh is the only way to get around this.
- Secondly, make sure that you have typed in the above xauth commands correctly, and that you have set the DISPLAY correctly (you could use xhost below to temporarily allow connections from the remote host, even without xauth, thereby testing your DISPLAY).
- Thirdly, make sure you have got the correct Magic-Cookie on the remote machine. You can do this by typing:
```
xauth list <Mac's-name-or-IP-address>:0
```
  This will show the entry in the xauthority file for your Mac's display. (Of course, if you read the security note above, you would also realise that it shows your Magic-Cookie to anyone who may be 'snooping' the connection between your Mac and the remote machine...)
  You can compare this with the Magic-Cookie that is in the local entry on your Mac:
```
xauth list :0
```
- Finally, if the ping command does get a response from your Mac, but you still cannot get through to the X server when starting X11 clients from the remote host, it may well mean that you have a firewall set up somewhere. First of all, check to see if you have enabled the personal firewall that comes with OSX10.2 - this will prevent anything getting through to your Mac's X server. If you do not have a firewall running on your Mac, you may have to find out if there is a firewall running on the network containing your Mac (most likely to be the problem) or possibly on the network containing the remote machine (less likely, since firewalls usually allow connections machines inside the firewall to create connections to any machines outside).

The final (unnecessary!) method is to use "xhost" with the DISPLAY variable
Before explaining this method (which, surprisingly, seems to be the most widely used), it is worth noting that there is really no need to ever use it, since xauth should work in all situations that xhost will work - and xauth is considerably more secure (at least, it is less insecure...)
It's also worth noting that the dreaded "xhost +" command, which seems to be used by a lot of people, is really quite dangerous! What you are saying is basically "let anyone do anything to me they want to".
Even restricting access to a particular machine (by using "xhost <remote-machine>") is still potentially quite unsafe - you are saying, in this case, "let anyone on that particular remote machine do anything to me they want to". If you know and trust everyone who uses that remote machine, all well and good. If not...
Having given those warnings, the basic method is very similar to xauth. But rather than taking a Magic-Cookie from the Mac to the remote host using the xauth commands, as above, instead you just tell the Mac to allow the remote host to connect to the X server. You do this by typing the following command just before you connect to the remote machine:
```
xhost <remote-machine>
```
Then you connect to the remote machine and set the DISPLAY there in the same way as with the xauth method.
When you have finished using X11 from the remote host, you should make sure you tell your Mac to no longer accept connections from it. You do this by typing the following on your Mac:
```
xhost -<remote-machine>
```
To get a list of all hosts that are currently allowed access, just type "xhost" on your Mac.
Any problems you encounter can be diagnosed using similar tests to those given above for xauth.