Nice summary of X11/XQuartz history. I miss something about Terminal.app which (I suppose) is still supported by Apple even in Mojave (but I stop at Sierra as long as my present bookpro lives, so I don’t know). Isn’t it another variant of X11 (except that there are some differences but I am not sure to know all of them)? Sep 22, 2017 - Turn on both X11, and Trusted X11: Host. ForwardX11 yes ForwardX11Trusted yes.
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.
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.
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.
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.
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.
-rob.
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?
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?
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.
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.
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.
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.
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.
What am I doing wrong? I would like to run these sessions inside the ssh tunnel to make sure they are encrypted.
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.
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.
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
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
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:
At the very top of the file, add the following 2 lines:
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.
In a terminal:
At the very top of the file, add the following 2 lines:
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.
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.
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.
just to add I forgot to mention after change the sshd_config you have to restart SSH
sudo SystemStarter -v restart SSH
:-)
sudo SystemStarter -v restart SSH
:-)
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?
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).
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).
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?
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)
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)
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.
Delete the ~/Library/Preferences/com.apple.x11.plist File
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.
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.
|
Import Virtual Machine Image
Once you have downloaded the .ovf image,
- Start up VirtualBox, then select File>Import Appliance and select the .ovf image that you downloaded.
- Next, press the 'Import' button.
Finish VM Setup
You will need to complete one more step before you are done with the VM setup.
Select your VM and go to the Settings Tab. Go to Network->Adapter 2. Select the 'Enable adapter' box, and attach it to 'host-only network'.(Sidenote: on a new VirtualBox installation you may not have any 'host-only network' configured yet. To have one select Global Tools -> Host Network Manager -> create or File -> Host Network Manager -> create. Click create with default settings. Then you can try the attach.) This will allow you to easily access your VM through your host machine.
At that point you should be ready to start your VM. Press the 'Start' arrow icon or double-click your VM within the VirtualBox window.
In the VM console window, log in with the user name and password for your VM. These should both be 'mininet'
Note that this user is a sudoer, so you can execute commands with root permissions by typing sudo 'command', where 'command' is the command you wish to execute with root permission.
Choose Preferred Editor
Nano, Vim, Emacs, and Gedit come installed on the OpenFlowTutorial VM. Brief instructions for each:
Nano: You can immediately modify a file. When you're done, hit 'ctrl-x', then say 'Yes' to the prompt, to save and quit.
Vim: to modify a file, type 'i' to enter Insert mode, then use the arrow keys to navigate and edit. When you're done, hit 'esc', type ':wq', then press enter, to save and quit.
Highly recommended for the NOX tutorial: add the following to ~/.vimrc in the VM:
Emacs: you can immediately modify a file. When you're done, hit 'ctrl-x', 'ctrl-s', then hit 'ctrl-x', 'ctrl-c' to exit.
Gedit: a graphical text editor, no instructions needed.
Eclipse: Eclipse and its dependencies would require about 500MB extra space on the VM image, so it's not shipped by default. If you have Eclipse installed on the host VM, using the Remote Systems Explorer can be a convenient way to access and modify text files on the VM, with many of the advantages of Eclipse, such as syntax highlighting.
If you have another preferred text editor, feel free to install it now:
Command Prompt Notes
In this tutorial, commands are shown along with a command prompt to indicate what subsystem they are intended for . For example,
indicates that the
ls
command should be typed at a Unix (e.g. Linux or OS X) command prompt (which generally ends in $
if you are a regular user or #
if you are root. Other prompts used in this tutorial include
for commands entered in the Mininet console and
for code entered into a Windows command window.
Set Up Network Access
The tutorial VM is shipped without a desktop environment, to reduce its size. All the exercises will be done through X forwarding, where programs display graphics through an X server running on the host OS.
To start up the X forwarding, you'll first need to find the guest IP address.
VirtualBox
If you are running VirtualBox, you should make sure your VM has two network interfaces. One should be a NAT interface that it can use to access the Internet, and the other should be a host-only interface to enable it to communicate with the host machine. For example, your NAT interface could be eth0 and have a 10.x IP address, and your host-only interface could be eth1 and have a 192.168.x IP address. You should ssh into the host-only interface at its associated IP address. Both interfaces should be configured using DHCP. If they are not already configured, you may have to run dhclient on each of them, as described below.
For more detailed instructions, see VirtualBox Specific Instructions.
![Mac os x11 forwarding Mac os x11 forwarding](/uploads/1/2/5/8/125847931/253981290.png)
Access VM via SSH
In this step, you'll verify that you can connect from the host PC (your laptop) to the guest VM (OpenFlowTutorial) via SSH.
From the virtual machine console, log in to the VM, then enter:
You should see three interfaces(eth0, eth1, lo), Both eth0 and eth1 should have IP address assigned. If this is not the case, type
Replacing ethX with the name of a downed interfaces; sometimes the eth ports appear as eth2 or eth3, you can fix this by editing /etc/udev/rules.d/70-persistent-net.rules and removing the existing configuration lines.
Note the IP address (probably the 192.168 one) for the host-only network; you'll need it later. Next, log in, which will depend on your OS.
Mac OS X and Linux
Open a terminal (Terminal.app in Mac, Gnome terminal in Ubuntu, etc). In that terminal, run:
Replace [user] with the correct user name for your VM image.
Replace [Guest] with the IP you just noted. If ssh does not connect, make sure that you can ping the IP address you are connecting to.
Enter the password for your VM image. Next, try starting up an X terminal using
and a new terminal window should appear. If you have succeeded, you are done with the basic setup. Close the xterm. If you get a 'xterm: DISPLAY is not set error', verify your X server installation from above.
Windows
In order to use X11 applications such as xterm and wireshark, the Xming server must be running, and you must make an ssh connection with X11 forwarding enabled.
First, start Xming (e.g. by double-clicking its icon.) No window will appear, but if you wish you can verify that it is running by looking for its process in Windows' task manger.
Second, make an ssh connection with X11 forwarding enabled.
If you start up puTTY as a GUI application, you can connect by entering your VM's IP address and enabling X11 forwarding.
To enable X11 forwarding from puTTY's GUI, click puTTY->Connection->SSH->X11, then click on Forwarding->'Enable X11 Forwarding', as shown below:
You can also run putty (with the -X option for X11 forwarding) from the Windows command line:
Open a terminal: click the Windows 'Start' button, 'run', then enter 'cmd'.
Change to the directory where you saved putty.
Run:
Replace [Guest] with the IP you just noted.
If putty cannot connect, try pinging the VM's IP address to make sure you are connecting to the correct interface.
Once the ssh connection succeeds or a terminal window for the VM pops up, log in to the VM. Now, type:
to start an X terminal (the -sl 500 is optional but gives 500 lines of scrollback.)
A white terminal window should appear. If you have succeeded, you are done with the basic setup. Close the xterm.
If the xterm window does not appear, or if you get an error like 'xterm: DISPLAY is not set,' make sure that Xming is running in Windows and that you have correctly enabled X11 forwarding.
Alternative: Run a GUI in the VM console window
As an alternative to running X11 on your host machine, you may find iteasier or more convenient to install a GUI into the VM itself. To install X11 and a simple window manager, log in to the VM console window - not via an ssh session! - using the correct user name and password for your VM, and type:
At this point, you should be able to start an X11 session in the VM console windowby typing:
If you are familiar with Linux, you may wish to install anotherdesktop manager (e.g. flwm if you want something even smaller/faster than lxde or even the full ubuntu-desktop) or any other GUI packages that you prefer.
Next Step
When you are finished setting up your virtual machine, follow the link below: