Remote X windows
Shell, admin, and both:
X windows was designed to be network-transparent. A number of modern extensions aren't, but these usually have to do with direct hardware access, so with minimal bother you can have X clients from another computer come to another - usually used to run things at a server but display locally.
It can be simpler to work with a remote display session instead of the slightly bothersome forwarding involved, though. Look into NX. For a slightly slower, single-user setup, look into VNC (which also persists the state of the desktop, not unlike screen for shells).
The short version
X is an inherently networked protocol.You can use a running, unused (or even used) X to make programs running on other computers display on yours, and you may already have used to make a program come to you. (You can even let another computer send its display manager - see the notes on XDMCP below. However, this only really works on LANs, so VNC and NX may be more practical)
|ssh -X||nearly none (assuming a SSH daemon)||Good (draw commands, tiny lag for encryption)||Easy: less fiddling than xhost, though the ssh server has to allow it.|
|X over local net||fiddling with xhost||Good (draw commands)||Host permissions may be annoying. To view from non-*nix, you need some X server software.|
|XDMCP + X server on local net||More involved (various configs, networking details)||Good (draw commands)||Quite practical once set up properly. (and could be done via VPN-style network)|
|VNC||Fairly simple (e.g. when following examples)||Acceptable (bitmap difference)||Session keeps running when you disconnect - can be handy|
|VNC + XDMCP||Could be involved||Acceptable (bitmap difference)||Can be useful for multi-user setups. Less restricted than basic XDMCP since that part can be local to the server|
|NX||Usually easy (sometimes a pain)||Acceptable to decent||Cleverer and faster than VNC. No additional auth (or encryption) details to think about as it just uses ssh. Some NX variations and combinations can be a little prickly to set up. If it works, it works, if it doesn't you may need to dig around.|
Note that 'local net' is not necessarily restrictive - that is, VPNs can make it practical over a distance, as do ssh tunnels (as mentioned).
Note on speed: Nothing deals well with fast-updating graphics like fading images and video (even a gigabit LAN connection would only be acceptably fast). If you use a flashier window manager (like KDE and recent versions of gnome), you probably want to turn off things like fading, expanding/collapsing menus and such.
TODO: read http://biohackery.com/node/38 and other things about NX
The longer version
Unless you know it well, you may want to skim over X terminology.
When you want to make X from another server come to you (or send it elsewhere) the easiest way is usually some form of tunneling, and the easiest among those is often tunneling provided by SSH.
SSH daemons on unices often supports tunneling X, and if the client you use also knows about X tunneling, most of the work will be done for you.
Usually, this works by having the SSH server allocate an extra display, such as localhost:10, and the X-tunnel-supporting client will point DISPLAY to this. To X clients running there, this looks and acts just like any other local (implicitly trusted) display, it just happens to be backed by a tunnel managed by sshd. This is also the reason you should not change the DISPLAY yourself. In the best case you send it to the same computer nonsecurely, but usually you'll just break it.
Of course, the ssh daemon has to support doing this, and it has to be enabled. It may be disabled for security/leanness reasons. If so, change your sshd config . Note that filenames tend to vary a little between versions and implementations - /etc/ssh2/sshd2_config versus /etc/ssh/sshd_config, that sort of thing.
For the fairly OpenSSH, the option is X11Forwarding yes. (Also, you want X11UseLocalhost to be its default, yes, unless you know that and why you don't.)
For the ssh.com server, it's AllowX11Forwarding yes.
Clients usually allow it out of the box. If not, the option is ForwardX11 yes.
A graphical *nix workstation almost always runs an X server on your graphics card on display :0, and most support running others on :1, :2 and so on - some modern linux distributions use that ability to support user switching.
X itself is a networked protocol, so X clients and servers need not be on the same computer - or use the same OS. There are several interesting alternative X servers:
- Cygwin/X is part of Cygwin, running under windows. Free, and runs the basics well.
- WeirdX is an X server implemented in Java, also free.
- Exceed is a commercial X server for Windows. In my limited experience it works well too.
- Unix versions of VNC servers are X servers, which then serve the graphical result over their own, bitmap-based protocol. A number of VNC implementations are free.
And some I never used myself:
- Reflection X
- X-Win32 (Windows)
- XLitePro, XSecurePro, XConnectPro (Windows)
- Xmanager (Windows)
- and more...
What and how
The X Display Manager Control Protocol (XDMCP) lets you graphically login to a remote computer. That is, it asks a remote host to connect to your X server.
It makes remote X logins about as flexible as local logins -- on local networks, anyway (XDMCP uses UDP, which means it can't be forwarded over SSH (as X itself can). If you want to do XDMCP over larger distances, you would use some type of VPN, probably an encrypted VPN to avoid all sorts of snooping of either protocol)
It works works by invitation: A host that would like XDMCP to manage it will advertize itself, inviting an XDMCP-capable host to connect to its X server.
XDMCP setups can be useful for users as it's a simple way of running things remotely but showing them on your client/workstation.
This can also be a handy way to use thin client, or reuse an old computer, to do little more than display all the work that's done on the more powerful remote host.
Using a login manager this way can be handy for admins, as logins will be mediated by this XDMCP host - a single place: XDMCP runs on some remote host, and itself runs a login manager (like like xdm, gdm, kdm). It runs on a remote host, and is just another X client that connects to your local X server.
(It also avoids the trouble of having to bake your own password setup, and deal with fixed screen numbers -- as is the case for multiple remote logins the VNC way)
- An XDMCP server should obviously be powerful when it serves more than one or two clients, as it's doing most of the work.
- Since you are running the X server that things get displayed on, there's usually no reason you can't have local X clients connect to it at the same time - though it can get confusing to you in that you don't necessarily know what came from which host.
- The XDMCP server is set up with XDMCP enabled (listens for connections - UDP port 117)
- Someone starts an X server, and either implicitly or explicitly either queries a specific XDMCP server, or broadcasts to ask whether there are any XDMCP servers on the subnet.
- The XDMCP server accepts the connection, or notices the broadcast. From the user's point of view, the XDMCP server starts connecting X clients to you. Usually, it gives a login screen as you would also get locally. Once authenticated, it will send you applications.
XDMCP uses UDP port 117.
The X protocol will need TCP ports dependent on the X server's display number: 6000+screennumber (6000 for :0, 6001 for :1, etc).
XDMCP is usually disabled by default since you need to know what you're doing to use it securely. The XDMCP server/port should only be reachable from the computers that should be able to use it, and more importantly, the X servers that connect to it should only accept X clients from the XDMCP server.
More specific access control is possible, and regularly a good idea since the very simplest methods open up XDMCP login to everyone on the local network. A simple option is usually to alter the XDMCP server's firewall so that the only hosts that can reach XDMCP (UDP port 117) are the ones you want to allow.
You may want to make the graphical end (X server) only accept incoming X protocol connections from the XDMCP host(s). Your client may do that automatically.
On the (XDMCP) Server side, you have a display manager - you can choose one, or use the one you use for local login. GDM or KDM are recommended somewhat over XDM.
Inform the system of the change/choice: set DISPLAYMANAGER, often in /etc/rc.conf or /etc/conf.d/xdm.
Alter the display manager's configuration to enable XDMCP. For example, for gdm this would likely be in /etc/X11/gdm/gdm.conf. Read the manual for details on the settings you're changing.
Once done, (re)Start the display manager. Make it start at bootup if it wasn't configured to do so. Note that the service will probably be /etc/init.d/xdm, regardless of which you configured.
On the XDMCP Client / X server side, you set up your X server to use XDMCP.
For programs that render X themselves, and X when setting up for thin clients, this is a configuration job.
Most regular workstations will also allow remote login: most login managers will have an alternative to local login hidden somewhere in the options, with options for a host query or a broadcast.
Broadcast means it will ask the local network segment whether there are any XDMCP servers (this may locked down). A query tries a specific host.
Example using Cygwin/X (windows) as a client
After installing Cygwin/X (requires a decent bit of basic Cygwin, which I don't otherwise use) I made a link in my start menu to a batch file I created at C:\cygwin\connect.bat containing:
@echo off C: chdir C:\cygwin\bin bash --login -i -c "XWin.exe -query 192.168.0.1 -keyhook -nodecoration"
Querying a specific server refers to an XDMCP query that will give you that server's login manager.
If you get only the checkered-pattern screen when you try this and no xdm/kdm/gdm/some other login screen shows up, this means no X client is actually connecting to you, usually meaning something like:
- that server is not serving XDMCP, or not doing so on the local network,
- the relevant ports are firewalled on one side or the other,
- the XDMCP query (which is UDP) didn't get routed (e.g. a TCP-only VPN),
- your local X server rejects the X client (often for authentication reasons)
You can usually tell from errors (or complete lack of response) in logs
Notes on that script:
- This is probably a dumb way, it leaves a cmd.exe window open, but it works. (I'm open to suggestions on how to get around that, but I wonder whether it's possible, at least in combination with XDMCP)
- -keyhook means alt-tabbing and such work within the X server
- -fullscreen would be nice, but for some reason it is exclusive with -keyhook (probably to avoid getting caught in your X display, though there'd usually be the windows key to get around that), however,
- -nodecoration is rather similar; it makes an as-big-as-your-screen root window without window borders, and it does combine with keyhook
There's also an option to have each program get its own client-side window (and to hide the desktop), which you may prefer when you like to work on two computers at once.
See also the Cygwin/X user guide