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:

  1. Use "ssh -X";
  2. Use xauth with your DISPLAY environment variable;
  3. 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?

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

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...

  1. 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"

    Once your DISPLAY looks like it is set up OK at both ends, you should be able to connect without any trouble.



  2. 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:

    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):



  3. 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.



About
OroborOSX
Version
History
Download |
|
Troubleshooting E-mail lists
and forums
|
|
Introduction to
X11 on OSX
About
XDarwin
XDarwin
forums
|
|
About
Oroborus