Remote desktops

Linux-related notes Linux user notes Shell, admin, and both: Shell - command line and bash notes · shell login - profiles and scripts ·· find and xargs and parallel · screen and tmux ·· Shell and process nitty gritty ·· Isolating shell environments ·· Shell flow control notes Linux admin - disk and filesystem · Linux networking · Init systems and service management (upstart notes, systemd notes) · users and permissions · Debugging · security enhanced linux · PAM notes · health and statistics · Machine Check Events · kernel modules · YP notes · unsorted and muck Logging and graphing - Logging · RRDtool and munin notes Network admin - Firewalling and other packet stuff · Remote desktops

X windows over the network

X is an inherently networked protocol

Some very practical 'but's are that

• we do so many fancy graphics that it doesn't network as efficiently as it used to

• locally we add many graphical extensions (hardware acceleration and more) that do not network well

...but you can still absolutely network it.

On your local machine, the X server is on the same machine, and you skip the networking

DISPLAY values of :0, :1, etc. refer to a local display

A number of modern extensions will only work when run locally -- notably hardware related ones, such as GPU features.

To do things remotely, you can trust whatever happens on a LAN but it's bad security practice.

💤

There was a period where networked X on a LAN was a sensible way to set up a certain kind of computer lab:

use mostly dumb terminals, meaning cheap hardware that was capable of little more than drawing on a screen

which were all connected to a single beefy server that ran the all the actual programs that a dozen or so dumb terminals were using

}

Even over a VPN it's not ideal.

A typical thing we do instead is use a SSH tunnel, because this is the easiest way to securely get around the sensible firewalling of such connections, and we need and usually have have an account on the host we're connecting to anyway

DISPLAY value will be something like localhost:10.0 (localhost due the the way SSH tunneling works)

💤

Terminology you may want to know: Each X application is an X client that you can connect to any X server An X server is the thing that draws things on the local network.

In fact even

the login manager (the thing you use to login) and

the display manager (the thing that shows you your desktop, and may be the parent process of all other apps)

are mostly just X clients like any other.

Note that

• any latency is directly visible,

so remote X makes less sense across oceans, and even the occasional latency hiccup of local wifi may be visible.

• the connection and the session are transient

one disconnect and all programs are gone

If you want a remote X session that persists between (re)connections, look at ways of wrapping it - VNC, NX, Xpra, etc.

some of these wrappers also have ways of dealing with lower bandwidth (sending a lower quality image, aggregating changes, sending changes often, etc.)

Some comparison

	Setup	Speed	Details
ssh -X	nearly none (assuming exising SSH server)	Good (draw commands, small lag for encryption)	Security (auth and encryption) is already handled. Some SSH servers disable X by default and your admin may have to configure it.
X over local net	fiddling with xhost	Good (draw commands)	Avoids SSH overhead. Host permissions may be annoying. Next to impossible over WAN, at least without VPN (and SSH may be simpler than VPN).
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 for users, or in some situations a pain for admin or security
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'

partly means "something with low latency" (which most broadband isn't, depending on your patience level), and

partly means "something where you don't have to do extra steps to get the traffic there at all" (internet access does not qualify -- but specific VPNs can again. As do ssh tunnels).

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 gnome), you probably want to turn off things like fading, expanding/collapsing menus and such.

The longer version

Unless you already know it well, you may want to skim over X terminology.

Tunneling

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.

X servers

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 (user apps) and servers (that display what apps/client send them) need not be on the same computer - or use the same OS. There are several interesting alternative X servers:

• XMing is sort of free ([this older version is, this is donationware) and runs on Windows (no GL).
• 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.
• MobaXterm [1] - SSH client plus X server. Windows-only, free version is limited.

• Exceed is a commercial X server for Windows. In my limited experience it works well too.

• *nix 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...

See also

X forwarding:

• http://www.csociety.org/~sigos/projects/ssh/forwarding/
• http://wiki.linuxquestions.org/wiki/X11_forwarding_with_OpenSSH
• http://www.cisl.ucar.edu/docs/ssh/guide/node29.html

XDMCP

The X Display Manager Control Protocol (XDMCP) asks a remote host to connect to your X server.

It can be used to graphically login to a remote computer, and was mostly used for thin clients (you can use it now, but it's linited in that it doesn't persist sessions).

See XDMCP notes.

VNC

VNC captures your screen and sends bitmap versions of it.

This is not very fast, but works and free servers and clients are available for Windows, Linux, and OSX, so can be an easy choice.

Practical details vary a bit with platform, and how it's set up. E.g. on windows you can only directly share a logged-in sessions, while on X you can host many completely separate sessions - or just share the current one.

Limitations:

• No encryption

...so run it over VPN, or SSH tunnel, if you do care about that

• Auth exchange looks decently secure(verify)

(clients storing passwords often less so)

• Various of the servers and clients are not in active development

• ...and those aren't the fastest thing out there

Can't really do live video, even if you've got the bandwidth (~5-10MBPs) to throw at it

that said, neither can most alternatives

Upsides:

• The VirtualGL thing is actually quite well done

• It being its own protocol makes it easily crossplatform

(e.g. unifying between X and others)

Notes:

• A VNC client connects to an IP and either a display-number-dependent port.

Port 5900+displaynumber is VNC itself

(Port 5800+displaynumber, if you see it, is for serving the java client, not used much)

Setup

Linux VNC server

Linux is more fundamentally multi-user than windows, so choose:

• Are you wanting to access existing graphical login sessions?

may be what everyday users want

Older days this was hard, or at least more involved. These days, GNOME and KDE have their own screen sharing to make this simpler. (TODO: details)

• If it's just for you, you can just run completely standalone session, as yourself

which are X servers upon themselves (drawing to a framebuffer shared via VNC, instead of to a monitor)

running as the user who started it

(There are further variants you can think up. My university had a bunch of VNC servers that ran just a login manager (XDM, GDM, KDM, or such) (...which then takes care of auth (implied by local config) and your choice of window manager (see eg. this), but that's a little odd of a setup in a few ways. Look into downsides when you do this.))

Classical

• run a new X server shared via VNC

vncserver :1 -geometry 1000x600 -depth 16

all arguments are optional, but

screen number is easier to remember if you specified it explicitly

screen size is fairly small by default

depth 16 will be a little easier on the network than 24, and a little uglier.

• TightVNC puts a startup file in which might e.g. contain

FILE ~/.vnc/xstartup

xrdb $HOME/.Xresources xsetroot -solid grey # sets a solid background (compresses better) instead of the default pattern xterm -geometry 80x24+10+10 -ls & # gives you a login shell twm & # a graphically simple window manager.

• once you want to stop it

vncserver -kill :1

With VirtualGL

• Have 3D drivers (and its development package) installed

• Install VirtualGL

e.g. package from https://sourceforge.net/projects/virtualgl/files/

• Install TurboVNC / TigerVNC

e.g. package from https://sourceforge.net/projects/turbovnc/files/

• Start vncserver as before

if you want to share your entire desktop, instructions are different - see e.g. vglserver_config

• run any GL app via vglrun so that it intercepts the GL.

Keep in mind that

• vncserver

from system packages is often tightvnc's (verify)

If you do the VirtualGL install, it'll be TurboVNC's (verify)

-->

VNC implementation details

The underlying protocol is RFB (Remote FrameBuffer) [2]

You want an implementation of it, and each adds its own things.

Implementations include... (newer ones first, roughly):

• TigerVNC - branch of TightVNC(/TurboVNC)

windows, linux, osx

In part meant to update TurboVNC, and provides a few modern features (RealVNC-like) and some TurboVNC updates, though for performance TurboVNC is generally preferable(verify).

http://www.turbovnc.org/About/TigerVNC

• TurboVNC - branch of TightVNC

windows, linux, osx

focuses on speed. By itself a little cleverer, so does better than tight at video and 3D content

the optional use of VirualGL gives more performance for 3D

the research / implementation details behind some of its design choices have been adopted by others, including TigerVNC, libvncserver, and recently UltraVNC

on Linux there is a server (verify) (see also VirtualGL instructions. Use of VirtualGL is optional)

on windows, the server end is recommended to be a post-2015 UltraVNC (verify)[3]

• TightVNC: server and client, free

windows and *nix

Otherwise fairly minimal (e.g. no GLX support in the server(verify))

Tight protocol was a good choice for a decent while (roughly until tiger/turbo)

Not actively developed

• UltraVNC: Similar to RealVNC, but free.

windows-only

supports e.g. tight

• RealVNC: server and client, free and paid-for versions,

windows-only

has extra features like file transfer. Seems targeted at helpdesks.

Other notes:

• "WinVNC" is a bit vague, in that more than one thing has been referred to as such (verify)

• about various turbos:

libjpeg-turbo is a SIMD-optimized variant of libjpeg (mostly drop-in)

TurboJPEG is a higher-level API which can be backed by libjpeg-turbo, or similar such optimizations

(developed for VirtualGL, TurboVNC)

TurboVNC's speed comes in part from using TurboJPEG, partly from spending less (CPU)time deciding what to send how

(itself in part because sending with jpeg is a bit cheaper via turbojpeg)

• about VirtualGL

intercepts rendered GL results in-process, works out as indirect but hardware-accelerated rendering

(where available; can also be built against mesa to be able to use 3D on GPU-less servers)

'intercepts' means itdoes not require apps to be built against it, you just have to start it in a specific way (vglrun)

which makes it pretty efficient to view 3D apps results (and video) rendered elsewhere on a fairly thin client (pretty impressive on LAN, by previous standards)

transport:

can do its own transport, e.g. displaying the results of one X (3D) server in another (2D)

perhaps more frequently seen with TurboVNC (or similar). This requires more CPU but provides other features, e.g. tending to be more reactive on high-latency, low-bandwidth connections.

associated but not tied to TurboVNC

http://www.virtualgl.org/

http://www.virtualgl.org/About/Background

• some special cases where one or more of the more modern details apply, e.g. in virtualbox (verify)

• Other/specialzed: See e.g. [4]

Helping you choose

• Multiple monitor support

Security

By itself, VNC is not encrypted.

Some implementations wrap it in some.

If you care about interoperability with other VNC clients, you may wish to look at

ssh tunneling

zebedee tunneling (apparently faster than ssh for this purpose) mentioned here

exposing a VNC server only over generic VPN

A password is hashed and stored for a particular server (usually per-user), always one for interaction, and possibly one for viewing.

Clients may store this hash (The TightVNC client can store all connection info in a file so that a simple double-click will reconnect you). Therefore: don't use your best password, it may be brute forcable. Of course, the same goes for the password hash on the server side.

Lower level details

Encodings

Usually less interesting (but the historic core so typically there)

• Raw

least latency added by extra work, but also the largest bandwidth needs.

usually less interesting, because in many all cases, Hextile can be at least a little cleverer

• RRE, and CoRRE, - basically a 2-D variant of Run-length encoding.

Efficient for large single-color-area interfaces like very simple GUIs, and perhaps office use, but for photographic regions.

less interesting to select specifically, when Hextile exists and uses it adaptively

• Zlib - higher compression than ZRLE butat higher CPU cost.

These days only useful as a fallback, e.g. when Tight or ZRLE are not available

Probably preferred in generic implementations

• Hextile - splits screen into tiles, uses RRE where useful, Raw otherwise

Basically "spend minimal CPU time on only the simplest gains" [5]

so often preferable over Raw and RRE, but still requires decent bandwidth.

E.g. makes sense for LAN office use, where auto will probably often end up on this

• Tight

based on zlib, with some pre-processing that should help compression ratio and CPU use

optional JPEG compression, with quality setting

making it a configurably amount of lossy

handy for low-bandwidth connections in that it allows that lossiness tradeoff

For high-bandwidth, low-latency connections, the extra processing may actually mean somewhat slower response than some others

• ZRLE - similar to tight, but:

came later than tight(verify)

lossless-only. Seems better at lossless than Tight

does fewer incremental upgrades than tight, so tight may seem faster on certain types of regions(verify)

For high-bandwidth the extra processing may actually be a bottleneck

specific to RealVNC, UltraVNC (verify), whereas tight is supported by more

• ZlibHex (Zlib compressed Hextile)

• Ultra - experimental, UltraVLC only.

Uses LZO compression, which is a more generic "whatever we can do for little CPU time" sort of compression

lossless, so that will by very little at photographic areas (like most encodings)

So in theory something inbetween ZLRE and HexTile

• TurboVNC

extends the tight protocol, giving more tweakability to JPEG

other improvements are optional use of libjpeg-turbo, multithreaded encoding, and ability to do interframe comparison

requires TurboVNC or TigerVNC server. Recent UltraVNC servers also support it (1.2.0.9, judging from the changelog)

• ZYWRLE ('ZLib YUV Wavelet Run Length Encoding')

lossy, video-aware.

May be a decent tradeoff when e.g. HexTile eats too much bandwidth and ZRLE is too slow.

http://forum.ultravnc.info/viewtopic.php?t=9167

used in which? Ultra

Notes:

• On "interframe comparison" (property of some encodings)

bare VNC often listens to frameworks saying "I redrew this region" and basically resends that

but while framework may be rethinking that entire region, it sometimes means updating relatively few pixels in it

so if VNC actually compares the pixels (to the previous pixels in that area) this may mean sending a lot less data, at the cost of some CPU in the checking

though when probably all be different (e.g. video, games), it's only a waste of CPU

• CopyRect option- will send only areas that update (for any, or just for raw?(verify))

generally helps, leave it on

• Cache Encoding option - needs CPU for checking, so is only worth it if you expect a bunch of areas to recur

regularly doesn't help, so you can leave it off

(note that artifacts from turbo mode and such can accumulate)

-->

See also

• http://www.uvnc.com/install/viewerconfig.html

Problems / Errors

Black right half in multi-monitor

(UltraVNC, possibly others)

Symptoms:

The data seems to get to you (scrolling left and right actually shows it)

making the window two monitors wide means the right side is black

Theory:

The UltraVNC client seems to allocate a viewport it will draw in.

By default this seems to be the first/left monitor's size (and order indeed seems to matter when you have monitors of different size).

Presumably the reason is that the client allocates this before connecting, i.e. before knowing how large this viewport should be(verify)

Evidence:

Some older clients allowed manual control this, with a dropdown that essentially listed each individual monitor size, and the combined desktop size.

Choosing the larger one works.

Workaround:

for me was an older client (e.g. 1.1.9.6), and choosing the largest size in that dropdown.

You probably also want to "save connection settings as default"

HOWEVER, once you maximize the window it goes wrong again.

So don't.

"Server did not offer supported security type" / "No matching security types" / "No security types supported" / "Unknown authentication scheme from VNC server"

VNC has a bunch of auth/security methods, and both sides have to support them.

I run into this mostly connecting to vino (e.g. Ubuntu desktop sharing) - by default it requires encryption, which most VNC clients out there do not support(verify) (More specifically, auth method rfbTLS, which is both auth and requires TLS)

So either

• Switch to a VNC client that supports rfbTLS encryption (e.g. remmina on *nix, realvnc on windows(verify)),
• tell vino to not require encryption. Know the security implications, though.

There is a vino-preferences, but it is just the basic settings that you also get via the taskbar icon.

To not require encryption, use dconf-editor to find and uncheck:

org → gnome → desktop → remote-access → require-encryption

"Unknown authentication scheme from VNC server: 18" (Remmina)

Not disabling encryption helps.

More details: https://github.com/FreeRDP/Remmina/issues/433

Ultravnc forgets password, and other settings (WinXP)

That is, the Admin properties dialog lets you apply things, but once you click OK the settings are not saved in your ultravnc.ini

In our case, file permissions were not the problem.

It turns out it was a WinXP anti-malware feature, specifically the "protect my computer and data from unauthorized program activity" checkmark on the "Run as" dialog that comes up when saving.

Uncheck that and you're fine.

See also http://www.uvnc.com/docs/uvnc-server.html

NX

NX is a protocol by NoMachine.

Proprietary, free for personal use. (There is open-source https://en.wikipedia.org/wiki/Neatx though it's not actively developed)

Crossplatform.

Typically faster than VNC.

Integrates VirtualGL, making 3D faster as well.

See also:

• https://en.wikipedia.org/wiki/NX_technology
• https://en.wikipedia.org/wiki/NoMachine

x2go

Roughly, NX 3 over SSH, with some

https://en.wikipedia.org/wiki/X2Go

https://wiki.archlinux.org/index.php/X2Go

SPICE

Mostly used in the context of virtual machines, e.g. being integrated into QEMU , oVirt.

There's also Xspice, basically an analogue of Xvnc.

Secure auth and encryptions.

Initially closed-source, now open-source.

See also:

• https://en.wikipedia.org/wiki/SPICE_(protocol)

ICA

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

ICA is primarily a channel multiplexer.

Screen content over ICA is actually thinwire, which e.g. has moving image detection [6].

This is used by Citrix - developed by them, in fact.

In practice, it's one of the nicest ways to run applications (instead of entire desktops) remotely, particularly in office environments.

https://en.wikipedia.org/wiki/Independent_Computing_Architecture

RDP

RDP (a.k.a. Remote Desktop, built on top of Terminal Services) started as a rebranding/spinoff/ripoff of ICA, simpler (and limited due to Citrix lawsuit threats(verify)).

rdesktop, tsclient, FreeRDP

Open implementations of RDP.

rdesktop is a CLI-started graphical RDP client.

FreeRDP is a fork that got some more development.

tsclient was (now discontinued) one possible GUI frontend for rdesktop.

You'ld now probably use Remmina, GNOME's or KDE's frontend - they and others tend to wrap/run varied clients.

RemoteFX

https://en.wikipedia.org/wiki/RemoteFX

Wrappers

Guacamole

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Guacamole is a HTML5 (canvas-and-javascript) frontend to a guac server, where that (extendable) server typically relays to RDP or VNC backends.

In other words, it makes it easier to unify and expose those.

See also:

• http://guac-dev.org/

Xpra notes

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Xpra (tmux/screen-like) persistence for X11: Apps are actually displaying to a background process, and gets relayed to you when you connect to that.

If you're familiar with X: It's an X server and (rootless) window manager (The Xpra client can also sync clipboard, sound, and printers, forward notifications, and some other potentially nice things.)

Xpra was designed to be rootless, meaning you get individual app's windows, rather than a desktop containing them. (This because Xpra acts as a window manager itself)

(also means that in practice you may well want to start a shell, as in the examples below)

You can get a desktop mode, by starting a nested X11 server as the initial process. Which then uses another display and a little more thinking - see the docs)

Quick start:

# start a new session on display :100
xpra start :100 --start-child=xterm
# in practice it can make more sense to add your initial program(s) to ~/.xpra/xpra.conf

# connect to it locally to test:
xpra attach :100

# connect to it remotely (via SSH, it's handy to do the auth and encryption for you)
xpra attach ssh:user@xpra.example.com:100

If you think the encryption is a bottleneck for you (or redundant because you're already on VPN), you can consider doing it via a direct TCP connection (optionally still with a password), something like:

# start like:
xpra start :100 --start-child=xterm --bind-tcp=0.0.0.0:10000

# connect like:
xpra attach tcp:example.com:10000

See also:

• https://xpra.org/trac/wiki/Usage

• https://wiki.archlinux.org/index.php/Xpra

Non-open

Paid-for

TeamViewer

Intended for remote assistance, cooperation.

Unattended access also possible.

Speed seems good, e.g. a bit better than VNC tends to be.

Paid version is slicker. And necessary for commercial use.

Free version used to do what you want -- except it seems they crippled it in 2021: it disconnects within a minute or two, and throttles reconnection.

Windows Remote Desktop

Remote logins

Remote logins, in the form of seeing another computer in a window and interacing with it, is possible when you have Windows XP or a recent server variant: both a server and the client, called either Terminal Services or Remote Desktop - it was renamed at one point.

On non-server versions of windows such as XP, there is a built-in limit that means you can only have one login at all, local or remote; logging in in one way will take over the same session, disconnecting the other. I forget whether this is fixable, but chances are microsoft doesn't really want you to do so. It's not a technological limit. In fact, they briefly promised it for SP2. I suspect it's rooted in the lessened motivation you would get to buy a server OS from them.

Interesting to note is that there is a linux client that works quite well.

Enabling

To enable it or verify it is enabled, right-click on 'My Computer', click 'Properties', and find the 'Remote' tab. Check the checkmark named 'Allow users to connect remotely to this computer'.

Remote assistance is, I believe, the same thing but established through invitations (for helpdesks and the like) and likely allows the connected to computer to look too (regular remote desktop throws the computer itself back to the login screen once there is a remote login). I never used it, so I usually disable remote assistance. (And given windows' track record in security, I feel a little safer disabling things I never use anyway)

Access control

The only things you have to set up is access control, under 'Select Remote Users'. Administrators are always allowed, and if you want to have regular users log in, you have to add them here. If, incidentally, you have a passwordless login, which people do to make their computer start up to their desktop without having to log in - you cannot use that particular account for Remote Desktop. Either you accept that and use another account (and accept that that won't give you the My Documents of your regular user) or you have to add a password to the account.

(The last is done via 'Control Panel', 'User accounts', <click the user>, 'Change my password'. You should do this as the user itself, and not as an admin, when possible.)

Linux client

rdesktop is a good option. Try to get the latest version. With a little option fiddling it should be able to fit most needs, including even thin client pseudo-windows machines.

You usually want:

• color depth to be high-color: -a 24
• to specify fullscreen -f, or a resolution, e.g. -g 1024x768

Also useful:

• -u loginname fills that in in the login. Probably most useful if you create a shell script with your options.

For speed, you can fiddle with:

• -x m disables the background, most fancy animations, etc.
• -m only sends mouse clicks, not motion. Less back-and-forth, but hovering and a few other things don't quite act like it should.
• -z compression - I've not noticed a big difference, though

From an applet

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Go to the properJavaRDP sourceforge page, or rather, the projects' download page.

Then try some howling on a full moon, because I can't get it to bloody work.

Unsorted

XDMCP notes

What and how

The X Display Manager Control Protocol (XDMCP) lets you graphically login to a remote computer.

Basically, it asks a remote host to connect to your X server with a client that shows/does session login stuff.

XDMCP 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.

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)

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)

Notes:

• 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.

Technical details

Connection process:

• 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.

Networking:

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).

Security:

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.

XDMCP setup

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