MJL20080827 — Update: I Just realised that this is one of my top-visited pages and it’s a totally disorganised and incongruent pile of… What’s worse is, I’ve never updated it since the promised update back in March 2007!
Let me clear things up (and save you wading through the whole article): If you want remote access to your openSUSE desktop from a networked thin client, then forget about X11, XDMCP, VNC or tunneling X through SSH. Use the NX protocol. You’ll need to do the following:
- Install FreeNX on your openSUSE host. Some (slightly outdated, but usable) instructions are in Chapter 9 of the openSUSE 10.2 Reference manual. If you’re using openSUSE 11.0 or newer, get the latest FreeNX package from the openSUSE Build Service (there are one-click install buttons)
- Install an NX client on your remote terminal(s). Nomachine has free NX clients for Linux, Mac, Windows and Solaris (even some experimental ones for PlayStation 2 and Zaurus!). If your remote terminal is running openSUSE, you could alternatively get an open-source NX client from the build service (or ask yourself: I’m running X locally, so why don’t I just use good ole SSH and X11?)
- Configure your NX client to connect to the openSUSE host, then log in and enjoy!
The upshot: I’ve done this with a FreeNX server and Nomachine’s NX client for Windows XP, and it all “just works”, except maybe for some font issues with older X clients like emacs (install extra font packages from nomachine to fix that), and some transparency effect issues I noticed in kwin4, probably to do with X11 extensions missing in the NX client. Not a big deal.
Read the rest of this article for the boring background and laughable false-starts in my quest for remote desktops in X… <blush/>
What I would really love to be able to do is get a graphical log-in screen to my openSUSE box, and have the KDE environment displayed onto a single window within the WinXP desktop on the notebook (sort of like Windows’ Remote Desktop feature
mstsc.exe, or the original X Terminals we used when I was a student at UTas back in the nineties). This way I’d have my full KDE desktop and it’d be really comfy to use. So what do I need to do?
Okay, I’ve finally had enough time at home to play with connecting to my openSUSE box from my work’s laptop (WinXP) over my wireless LAN. It’s all groovy: I can use PuTTY, or Cygwin‘s
ssh command (
ssh -Y to enable X11 tunnelling) to log in, list files, run programs (even X clients, so long as I’ve started Cygwin’s X server first) and it’s all secured by an SSH tunnel through the air between my study and my back deck (favorite place to work ). Note that using 802.11g is probably a little slow for running intensely graphical X clients like photo viewers or
xaos ( ), even with a strong signal, but it’s good for running an IDE or Konquerer. And if you add the
-C (Compress) switch to
ssh, it speeds up the intense app’s nicely!
Well, obviously I’ll need to start X on the WinXP box, without
-multiwindow, and to
-query for an XDMCP server on the openSUSE box. This should work, since I use a graphical login on openSUSE, which means an XDMCP server is already running (KDM). So I’ tried that, and it doesn’t work. Why?
It turns out that nearly every Linux distro’ has configured their X display managers (kdm, xdm or gdm) to disable XDMCP access from external servers and instead only allows connections from
localhost (i.e. from the Linux machine itself).
Why have they done that? Because XDMCP is insecure: it transmits passwords in clear. Also, you cannot secure XDMCP with SSH, as XDMCP uses UDP as well as TCP protocols . So it’s insecure and it cannot be fixed, therefore distribution providers (wisely) disable it. If I want to have a remote desktop as opposed to just seeing individual windows in my Windows desktop (which is cool, but not what I want), then I’ll need to either not use SSH and be insecure, or use something else like VNC.
I’m going to opt for the (insecure) option of not using SSH for X desktop access, and stick to traditional XDMCP sessions. My reasons for this are:
- I want it to be simple, and with as little overhead as possible (using VNC involves mucking about with session IDs, or running an extra X server on the Linux side)
- I only intend to access my Linux desktop from within my (W)LAN. I have a firewall in the router, so I can set it to disallow access to ports UDP/177 and TCP/6000 from the Internet (or, if it proves too difficult to do it at the router, I can set openSUSE’s own firewall to do that)
- My WLAN is encrypted over the air anyway (WPA/PSK) and it’s also using a silent SSID and a MAC-address white-list, so it’s pretty secure already. The only way for somebody to sniff out my password is to be physically attached to my router
- So far I feel I can trust every computer attached to the LAN, since it’s my own house. If (when?) this changes (that is, once my son is old enough to hack the network, so maybe when he’s about eight years old?), I might revisit tunneling XDMCP sessions via VNC through SSH.
So, how do you set up good ole’ XDMCP under Linux? READ THE FINE HOW-TO. It’s that simple, just remember that this is not secure kids. If you need security, use VNC, or just
ssh -Y to your Linux host and run individual X clients (with an X server on your local machine). I’ve also read in a mailing list that it’s possible to start KDE from an SSH session anyway. I might give that a go first, since it would be nearly as simple as XDMCP, and also secure. But I really want my desktop, so we’ll see what happens first….
2007-03-26T08:22+1000 Update: — Some mixed success
I’ve learned a couple of things over the week-end:
ssh -CY(use gzip compression when transmitting packets) produces satisfactory speed for
gwenview, even over my WLAN
- PuTTY doesn’t seem to work any faster, even with Compression Enabled. Perhaps it doesn’t support OpenSSL’s compression? I don’t know. Anyway, I don’t need PuTTY as long as I have Cygwin with
- You can start the KDE desktop from an
sshsession with the
startkdecommand. However in openSUSE (at least my install) this takes a long time to start, and eventually
kwinhangs on the notebook end. On the client end (the openSUSE box), it maxes out the CPU
So that was exciting and a little disappointing. I’ll need to experiment a little more it seems. I got expected warnings about missing font paths and ALSA not working, but I was still hoping to get the desktop up, just with some reduced functionality. There were also warnings about certain X server extensions being unavailable on the Cygwin X server, which I didn’t expect, but again, they aren’t critical (no transparency support etc.). Perhaps there’s some environment variables that KDM sets which are causing kwin or other desktop subsystems some grief when missing?
If I still can’t get it working soon, I might start with XDMCP, or I might skip straight to VNC after all. One other thing to try before getting too drastic is to see if the Linux on my notebook’s VMWare can run my KDE desktop remotely, or to try booting the notebook from a LiveCD such as Knoppix….
2007-03-29T16:48+1000 Update: — RTFM. Indeed!
It’s amazing what you can find out if you just read the manuals that come with your software. Feeling silly now…I was exploring the openSUSE Reference manual on the train home last night. Chapter nine is particularly interesting: it describes FreeNX, a free remote desktop server, all ready to go on openSUSE, just install and follow the instructions. There’s even an NX client for Windows. Much simpler, and still Free.
Looks like this is the way to go. I’ll try it out and do a (hopefully) final update.