Everything compiled against GNOME and KDE is intrinsically X Window-enabled. Once the X11 apps are in your PATH, you can go snooping around. You may need to specify the path to your remote system's stash of X11 clients. Now, whenever you run an X11-enabled app in that ssh session, the application runs on the remote machine and automatically opens its windows on your Mac. The answer should come back "localhost:10.0" unless the remote machine has been configured differently. When ssh -X connects, it will ask for a password, just as regular ssh does. You have to be able to access that machine via ssh, of course, which requires that you set up sshd (the SSH daemon) on the remote box and exchange credentials. When run from inside xterm on your Mac, this command creates a tunnel from the remote machine to your X server. Fortunately, some creative melding of X11 and SSH, the secure shell, gave us this gem: Reaching across LAN segments, or through NATs and firewalls, was no picnic without resorting to VPN.
The toughest thing about X11 used to be arranging for X11 clients to see your server. They reach out to your server to tap your display, keyboard and mouse, but with far lower networking and compute overhead than full-screen remote desktop sessions require. X11 applications on remote hosts are clients. The X11.app that you run on your Mac is the server.
#Mac os xterm to remote terminal software#
In X11 parlance, the X11 server is the software that handles communications and renders client content. Now we get to the most important step, which, once you understand the whole X11 client/server thing, is a walk in the park. In my previous two posts on the subject, I explained why you'd want to use X11 to drive a host remotely, and the basics of configuring your Mac to run OS X's X11 server and to use local X11 software.
0 kommentar(er)
