Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Run apps on Apple's X11 server from other machines UNIX
One of the great things about X11 is that it operates as a networked client/server application, so you can allow other hosts to run X11 applications using your server to display. Here's how to configure OSX to allow this (assuming you have Apple's release of X11 installed):
  1. Add a new rule to your firewall (System Prefs -> Sharing -> Firewall -> New) with the port name = "X11" and the port number = "6000"
  2. Start X11
  3. In your xterm type xhost +
And that's it. Now, for example on a local UNIX machine you could do the follwing:
 $ DISPLAY=myosxmachine.foo.com:0.0
$ export DISPLAY
$ xv
to run an instance of the image viewer xv on the OSX machine's X11 server.

What you've done is to A) Open the firewall for port 6000 (the X11 port) and B) Allow anyone to use your X server (xhost+). Be aware of the implications of doing this however, and make sure you read up on the 'xhost' command and how to limit access only to the hosts you trust (tyep man xhost).

[Editor's strong caution: Please see the comments for why this is a Bad Thing to do! The right way to use this command is with an actual IP number or host address in the xhost command, as shown in the comments. You can also use the ssh syntax shown in another comment ... my apologies for running this as is without testing and researching first.]
    •    
  • Currently 3.00 / 5
  You rated: 5 / 5 (2 votes cast)
 
[11,762 views]  

Run apps on Apple's X11 server from other machines | 19 comments | Create New Account
Click here to return to the 'Run apps on Apple's X11 server from other machines' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Dear God No.
Authored by: ChrisMMF on Jan 14, '03 10:59:02AM

I realize that Mac users are not, historically, X11 users and it's mostly us refugee Unix geeks that have X11 experience, but this hint is flat out reckless.

What you've done is open a hole into your system and allow anyone anywhere to connect to it. The process they're connecting to runs as root. If there happened to be any type of security hole in the X11 server, absolute havoc could reign. Apple's X11, XDarwin, and the rest of the X11 servers for OS X are all based on the XFree project, and it's a reasonably well put together codebase, but it's HUGE. There's always the possibility for something to be missed. This is the same XFree that is used in every BSD and Linux distribution out there.

Moreover, you're also allowing anyone who wants to to display windows at random on your screen. That's what xhost + does. It would be less than trivial for me to write an X11 app that looked like the Apple Admin password requester and display it on your screen. You think pop up ads from your browser are bad?

Think that's the total problem? Nope. If I got XKey, and attached it to your server's port 6000, I could get a dump of ALL keystrokes and mouse movements into X11 apps. Writing a doc into OpenOffice? I've got it. Typing a password into some X11 app? Mine.

Does this mean you shouldnt remote display X11 apps? Absolutely not, once you use it, you'll find how incredibly useful it is.

What you do is, open the firewall, but, don't use xhost +. For xhost, + is a wildcard. It means that any host, anywhere, can connect and display.

Instead, use xhost some.host.name, or xhost x.x.x.x with an IP. This allows only that single host to send windows, and is much safer.



[ Reply to This | # ]
Re: Dear God No.
Authored by: ChrisMMF on Jan 14, '03 11:13:17AM

Yes, I did notice the warning at the bottom of the story about controlling this, but it wasn't a strong enough warning. You should never, never need xhost +. xhost with a hostname or IP should ALWAYS be your default.



[ Reply to This | # ]
Thanks!
Authored by: robg on Jan 14, '03 11:18:36AM

Sometimes in my rush to get through everything, I don't catch all that I should. I should have added more details here ... sorry!

-rob.



[ Reply to This | # ]
A better way...
Authored by: gospodin_david on Jan 14, '03 11:12:50AM

I'm assuming that this works everywhere, it has for me so far...

An easier and more secure way to do this is to ssh to the host on which you want to run a remote session on with the -X flag. "ssh -X hostname" will enable X11 forwarding over a secure connection. You can then run graphical applications on the remote machine (just type the name of the executable that you want to run in the secure shell window) with the display being on your own. This, of course, assumes that the host to which you want to connect supports ssh sessions. Then again, would you want to use a host that didn't even have that?



[ Reply to This | # ]
A better way...
Authored by: PeterPan on Jan 14, '03 12:29:45PM

Note that you need to manually edit your /private/etc/sshd_config and your /private/etc/ssh_config files to allow X-Fowarding (remove the # from the start of the line X-Forwarding No, and change the No to Yes).

You will need to restart the sshd (using terminal kill -9 pid, then run /usr/sbin/sshd) or restart the OS X box.

This has great advantages in terms of remote monitoring, network monitoring etc. or even editing word docs on your home machine (with Open Office etc..) and is nice and secure....

Hope this helps.



[ Reply to This | # ]
A better way...
Authored by: dieter on Jan 15, '03 05:39:46AM

just some more unix lore: instead of explicitly killing and re-starting sshd (or other daemons), sudo kill -HUP <pid> causes the daemon to read its configuration files without terminating.



[ Reply to This | # ]
set up your ~/.ssh/config
Authored by: awk on Jan 14, '03 12:34:27PM
Yes, this is probably the ONLY proper way to run X11 apps remotely. I wouldn't even think of opening port 6000, no matter what the access controls are set to! Of course if you're just on your own private LAN, behind your firewall, you could run direct for maximum speed but the best thing is to set up SSH to forward your X11 sessions by default. Instead of -X you can also add ForwardX11 yes to your ~/.ssh/config (create it if it doesn't exist), and then you'll have X11 port forwarding as the default. You can verify that your connection is secure by logging into a remote host with SSH and checking the DISPLAY variable: echo $DISPLAY .. it should return "localhost:10" or something similar. This means the X11 stuff is going to the remote host and transported via SSH over to your local display. You might have to set X11Forwarding yes in the remote host's /etc/sshd_config (or equivalent). I believe this is off by default on Darwin. Be sure to restart the sshd daemon (a reboot will do the trick). You can set this up for certain hosts only, and you can also set it system-wide for all users. Read the man pages on SSH for more info.

[ Reply to This | # ]
set up your ~/.ssh/config
Authored by: bogen2 on Jan 15, '03 11:47:55AM

I just don't see how this works. First of all, even with a firewall in front of the X client, I can set the display variable in a normal ssh session and then run any X app successfully, as the firewall will permit all outbound connections and only ssh inbound. Because you are running the app from inside the firewall, it can reach out and connect to port 6000. But I still wanted to make it work, so I used ssh -X host to connect, but nothing changed. I tried setting the display to 0.0 and leaving it blank - didn't work at all. Tried settiing X11Forwarding in both ssh_config and sshd_config and connections work the same as with a normal ssh session. Doing an echo $DISPLAY always shows the address of the X server, not localhost. And netstat on the server shows a connection to port 6000 from the client. Sigh.

What am I doing wrong? I would like to run these sessions inside the ssh tunnel to make sure they are encrypted.



[ Reply to This | # ]
set up your ~/.ssh/config
Authored by: geltmar on Jan 19, '03 06:37:26AM

Try to login with ssh -v -X other.unix.system and watch the extensive debugging information.
I had some similar problem and found out, that xauth was not installed on other.unix.system and the DISPLAY environment was not forwarded because I could not be authenticated.
But maybe the debugging information will point you in another direction. Give it a try.



[ Reply to This | # ]
set up your ~/.ssh/config
Authored by: badragoo on Aug 19, '03 10:21:41PM

So, it's months later. I came across your question because I was having the same problem. My solution was this: Before you get too far in, first make sure you can type the name of a local X11 application (something like xclock) into a prompt in your Terminal.app window and have it appear locally on your X11 desktop.

If you get a "can't open display" error when doing that, then you'll never get it working across a remote connection. So you first need to do something like this (assuming you're using the default csh shell):

setenv DISPLAY :0

This tells Terminal.app to display X11 applications in your local X11 server. Once you get that working, go ahead with your ssh connection to the Unix machine:

ssh -C -X unix.machine.here

Then try to run something simple like xclock remotely (assuming it's installed on your remote unix box. That's all I did to get it working.

-bpd



[ Reply to This | # ]
Another ssh method
Authored by: apparissus on Jan 14, '03 12:39:34PM
Instead of typing ssh -X unix.machine.name every time, you can use pico, emacs, etc. and edit ~/.ssh/config. Here's the procedure using pico:

In a terminal:
pico ~/.ssh/config

At the very top of the file, add the following 2 lines:
Host unix.machine.name

ForwardX11 yes

You can also replace "unix.machine.name" with "*" in the Host line to enable it for all hosts you ssh to. This is the way I have mine set up.

[ Reply to This | # ]
2 Steps to enable X11 forwarding
Authored by: harpdog on Jan 14, '03 04:01:13PM

I already have SSH configured securley and use it only with public keys and not passwords.

After insalling apple X11 I just change the line in my sshd_config on my server

to

X11 Forwarding yes


Then on my client machine I engage the tunnel

ssh -2X username@serverip


That is all I needed to do, nothing else.



[ Reply to This | # ]
I mean 3 Steps to enable X11 forwarding
Authored by: harpdog on Jan 14, '03 04:04:57PM

just to add I forgot to mention after change the sshd_config you have to restart SSH

sudo SystemStarter -v restart SSH

:-)



[ Reply to This | # ]
what is mesa?
Authored by: student on Jan 14, '03 03:49:50PM

there is unix server that i am trying to log into but it does not use native OpenGL but uses Mesa. apple's x11 does not use Mesa. what are the alternatives?



[ Reply to This | # ]
what is mesa?
Authored by: porkchop_d_clown on Jan 14, '03 05:04:00PM

That shouldn't matter for most X applications - what goes over the network are sort of "API calls" - a generic interface to any X server. In fact, your Mac should inform the remote system what your X server's abilities are when you connect.

The only place I can see that this would be a problem is if you're trying to run an application on the remote box that uses Mesa (Mesa is a linux library for 3d graphics, BTW).



[ Reply to This | # ]
what is mesa?
Authored by: student on Jan 15, '03 05:24:11PM

If you know about the crystallographic database in daresbury in england they use mesa to run programs such as conquest, vista and pluto to view crystal structures. does apple apple x11 capable of running mesa? is there a way to add mesa compatiblity to apple's x11?



[ Reply to This | # ]
what is mesa?
Authored by: nmhansen on Jan 14, '03 09:58:38PM
Actually, Mesa is a native implementation of OpenGL for Linux and BSD...

And that should be no problem. I've written stuff for OpenGL on my schools Linux boxes, then "ssh -X"ed in and was able to run my program with Apple's x11.app. As long as you are using the quartz-wm, everything should work just fine (albeit slow)

[ Reply to This | # ]
Addendum to ssh -X flag
Authored by: Anonymous on Jan 14, '03 09:13:57PM
Add -C and you'll get compression as well, which can be useful over slow links. Throw ssh keys into the mix (see here) and you can make a trivial script which lunches X11.app, checks for quartz-wm, then issues the "ssh -X -C myremotebox.mydomain.com /usr/local/bin/myXapp &" combo, and voila, compressed ssh X forwarding, no password prompt, with display on your local box. Nice.

[ Reply to This | # ]
Delete the ~/Library/Preferences/com.apple.x11.plist File
Authored by: forman on Jul 17, '05 01:22:28AM

I had a bug in which I could not run "xhost" on my Apple and thus couldn't run remote X11 applications. The solution (after a couple of hours of debugging) was to delete the "~/Library/Preferences/com.apple.x11.plist" file. After that everything worked fine.

The primary symptom is, if the program "xhost" is run on the local Apple, it will fail with "xhost: unable to open display "localhost:0.0.

Michael.



[ Reply to This | # ]