![]() |
OroborOSXMore than just another window manager!
|
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:
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 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!
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...
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...
ssh -X <remote-machine>
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.)
alias ssx ssh -C -X -c blowfishSo now all I have to do is type:
ssx <remote-username>@<remote-machine>
How to diagnose problems when using "ssh -X"
In such a case, it's probably worth asking the owner/administrator of the remote machine why there's no sshd running on it, since it really is the only truly secure method listed on this page...
echo $DISPLAYIt 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.)
echo $DISPLAYIt 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 yesIf 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.
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:
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 ~/.XauthorityIf 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 . ab12cd34ef56fe78dc90ba1a2b3c4d5e6fIt'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 .
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 :0This will return a line which looks something like this:
localhost/unix:0 MIT-MAGIC-COOKIE-1 b3942f4becd56efb9d7889cc6ff6b1c9The 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.
setenv DISPLAY <Mac's-name-or-IP-address>:0At 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.
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...
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):
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.
xauth list <Mac's-name-or-IP-address>:0This 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
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 |