Enable multiuser logins with VNC

Help your users access a multiuser Linux system from anywhere


VNC and X server architectures

Linux® uses the X Window System (X for short) as its graphical user interface (GUI). X is an unusual GUI in several ways, one way being that it's inherently network enabled. An X server is literally a network server program. Network server programs give client programs access to local resources, and this is true of an X server, as well. The oddity is that the "local resources" in the case of an X server are the display, keyboard, and mouse, which the user uses. In the most common configuration, the X client programs run on the same computer as the server. Thus, LibreOffice, the GNU Image Manipulation Program (GIMP), or other programs are X clients that use X's network protocols to accept user input and display output for users on the same computer.

When X is used over a network, though, the user sits at the X server computer, and X's clients are the programs that the user wants to run on another computer. This configuration requires a second network protocol to initiate the connection. This second protocol can be telnet, Secure Shell (SSH), or the X Display Manager Control Protocol (XDMCP). The server for this login protocol runs on the X client computer, and the remote login client runs on the X server computer. The remote login server launches X clients that in turn contact the X server. Figure 1 depicts this relationship. Dashed arrows denote session initiation. (In the case of XDMCP, the XDMCP client is built into the X server program.)

Figure 1. X remote access requires a client and a server on both computers
Diagram showing the relationship between X clients and an X server
Diagram showing the relationship between X clients and an X server

This type of setup works fine on many local networks, but it has drawbacks. For instance, this configuration requires two-way network protocol initiation, which might not be possible through some firewalls or network address translation (NAT) routers. (SSH can tunnel X sessions, obviating this need.) Furthermore, although X servers are available for most platforms, they're not routinely installed on computers running Windows®. For these and other reasons, many sites prefer to use another protocol, the Remote Frame Buffer (RFB), which is implemented in the Virtual Network Computing (VNC) family of programs.

VNC is a cross-platform tool that can provide remote access to Linux, UNIX®, Mac OS X, Windows, and other systems from any type of client. With VNC, the user sits at the client computer and accesses a remote server computer. On Linux, the VNC server either mirrors the contents of the local X server's screen to the remote computer or includes its own X server that can operate independently of the one that manages the local screen. The result resembles Figure 2. Again, the dashed arrow indicates session initiation. This configuration eliminates the need for the reverse network connection, and because VNC clients and servers exist for so many operating systems, users can employ a single client program to access any server.

Figure 2. A VNC server includes an X server that can communicate with local X client programs
Diagram showing how VNC servers sends X server content to clients
Diagram showing how VNC servers sends X server content to clients

The downside to VNC is that RFB authentication is based on passwords without user names. Thus, each user must launch an independent VNC server session and connect to that VNC instance by specifying the correct port number. This requirement might be tolerable on a single-user system, but is extremely awkward on a multiuser computer.

To work around this issue, you can link the two approaches. You can reconfigure your local XDMCP server to help the X server integrated in VNC provide the missing multiuser authentication (the resulting configuration resembles Figure 3). The dashed arrow indicates session initiation. Now, when remote VNC users contact the VNC server computer, they'll be able to enter their user names and passwords to access their own unique VNC sessions, so the computer can handle as many users as you like.

Figure 3. Adding XDMCP to a VNC configuration provides extra flexibility
Diagram showing how adding XDMCP to a VNC configuration provides extra flexibility
Diagram showing how adding XDMCP to a VNC configuration provides extra flexibility

Configuring your VNC server

Several ways to launch VNC exist, including using scripts, linking VNC to your desktop environment using desktop tools, and using xinetd to listen for VNC connections. This last approach is the one described here, because it enables you to launch VNC so it can use your XDMCP server. Before detailing how to configure VNC to launch through xinetd, you must select a VNC server.

Selecting a VNC server

Several VNC server programs are available. (Related topics provides pointers to several.) Some of the more popular options include TightVNC, TigerVNC, and RealVNC. This article uses TightVNC as an example. Unfortunately, configuration details vary from one server to another as well as from one distribution to another, so you might need to adjust the instructions provided here for your software.

Installing xinetd

Many distributions install the xinetd super server by default, but some do not. Because the method described here uses xinetd, you should install xinetd if it's not already installed. On most distributions, you can install xinetd by using the package system, such as apt-get install xinetd on Debian-based distributions or zypper install xinetd on openSUSE.

You might also need to configure xinetd to run. You can typically run it on a one-time basis by using its System V (SysV) startup script:

# /etc/init.d/xinetd start

Configuring xinetd to run automatically when the computer boots requires knowledge of the startup script methods for your distribution. Typically, you use a utility such as chkconfig (used in Fedora, openSUSE, and related distributions), update-rc.d (used in Debian and related distributions), or rc-update (used in Gentoo) to do the job, as in:

# chkconfig xinetd on
# update-rc.d xinetd enable
# rc-update add xinetd default

Type only one of those commands, or locate an equivalent for your distribution.

Note that xinetd may refuse to start if it doesn't have any services configured. Thus, you may want to put off launching it until you've configured xinetd to manage your VNC server.

Configuring xinetd

Servers that should be managed by xinetd place configuration files in the /etc/xinetd.d directory. Thus, to configure xinetd to handle VNC, you should create or edit a file with a name such as /etc/xinetd.d/vnc. (On some distributions, such as openSUSE, the VNC server package installs such a file.) Listing 1 provides an example.

Listing 1. An example VNC configuration for xinetd
service vnc
   disable     = no
   socket_type = stream
   protocol    = tcp
   wait        = no
   user        = nobody
   server      = /usr/bin/Xvnc
   server_args = -inetd -once -query localhost -geometry 1024x768 -depth 16
   type        = UNLISTED
   port        = 5900

This entry sets several xinetd options, most of which you should leave alone. Those you might want to adjust include the following:

  • service. You can run VNC on multiple ports with different options on each, but if you do so, you should give VNC a different service name for each port on the first line in Listing 1.
  • server. You should change this entry to point at your VNC server's main binary, which is usually called Xvnc.
  • server_args. You'll almost certainly want to change some of these options, as described shortly.
  • port. VNC uses ports numbered 5900 and up. You can run the server with different options on different ports. If you do so, you should assign each instance its own port number.

The trickiest part of the xinetd configuration is setting the server arguments. You can use the arguments in Listing 1 as a model, but you might want to change some of them:

  • -query localhost. This option tells the VNC X server to check with the localhost system for XDMCP authentication. You can change it if you want to use one computer as a relay to access programs on another one.
  • -geometry 1024x768. You set the virtual resolution of the VNC session with this option. Note that this resolution doesn't need to resemble the resolution of the regular X server running on the server computer. You might want to create multiple entries running at different resolutions to enable users to log in to the VNC server using whatever resolution is convenient for their own local systems.
  • -depth 16. This option sets the color depth. Lower values can produce faster display updates, but high-color desktop environments can suffer from color artifacts. Valid values range from 2 to 32.

Many other options are available, and some vary from one VNC server to another. Consult the documentation for your VNC server to learn more.

Configuring your XDMCP server

Most Linux distributions configure their XDMCP servers to manage the local display and nothing else. To provide remote access, you must reconfigure your XDMCP server to accept access requests from the VNC server that runs on the same computer. The details vary from one XDMCP server to another. The three in most common use on Linux are the GNOME Display Manager (GDM), the Light Display Manager (LightDM), and the KDE Display Manager (KDM). Other XDMCP servers, such as XDM, require different adjustments than those described here. In any event, after reconfiguring your XDMCP server, you'll have to restart it.

Editing the XDMCP configuration file

If you're not sure which XDMCP server your system uses, you can identify it by searching a process listing for the string dm, as in:

$ ps ax | grep dm
  929 ?        Ss     0:00 /usr/bin/kdm
  962 tty7     Ss+    0:19 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth \
30157 pts/3    S+     0:00 grep --color=auto dm

The first line of this output reveals that KDM is running, so you would have to edit this server's configuration file to enable VNC to use XDMCP. Most XDMCP programs have configuration files that follow a similar format. They include sections that are identified by section names in brackets, such as [xdmcp]. Lines following the section name set options using an equal sign, as in enable=true. Table 1 summarizes the configuration file names, section names, and options you must set to enable XDMCP on several common Linux XDMCP servers.

Table 1. Options to enable XDMCP support for VNC for various XDMCP servers
XMDCP serverConfiguration file nameSection nameOption

You might find the XDMCP section in your configuration file, or it might be absent entirely. If present, it might explicitly disable XMDCP support, contain commented-out options, or be empty. Whatever the original state of the file, you want to ensure that the XDMCP section is present and that this support is enabled. As an example, consider a KDM configuration to enable XDMCP:


Some distributions enable extra security measures that you might need to loosen. One of these is a firewall. Firewall scripts tend to be distribution specific, so consult your system's documentation to learn how to modify your firewall. You should ensure that localhost has access to port 177 and that your VNC clients have access to port 5900 (or whatever other ports that you use for VNC).

OpenSUSE uses an extra configuration file that controls some types of access, including XDMCP access: /etc/sysconfig/displaymanager. Open this file in a text editor and search for the following line:


Change this option to "yes". If it's left at "no", the login prompt of your XDMCP server is not visible when you connect to the VNC server. This change is not required on most distributions: Only openSUSE uses this file.

Restarting the XDMCP server

With your XDMCP server configured to accept remote logins, you must restart it. On distributions that launch X through a SysV init file, such as Debian and Gentoo, you can pass it the restart option:

# /etc/init.d/gdm restart

If your system uses the runlevel number to start X, such as Fedora and openSUSE, you'll need to switch to a text-mode runlevel (typically 3), and then back to the GUI runlevel (typically 5):

# telinit 3
# telinit 5

Be aware that either approach shuts down X, so ensure that you have saved all your open work in your X session before proceeding.

Testing and debugging the configuration

At this point, you should be able to log in from a remote computer using a VNC client. For instance, most Linux distributions provide a command called vncviewer; you can type:


. . . to log in to remotename through VNC. The result, when VNC is configured and working correctly, resembles Figure 4. If you've configured multiple VNC sessions on different ports, you can specify the VNC session number by passing it as part of the hostname, as in:

vncviewer :3

. . . to log in to session 3 (on port 5903).

Figure 4. When configured to work with XDMCP, VNC provides a traditional Linux login prompt
Screen capture of a traditional Linux login prompt in VNC
Screen capture of a traditional Linux login prompt in VNC

If you don't see an XDMCP login screen when you perform this test, you have some debugging to do. Some things to check include:

  • If vncviewer reports that the connection was refused, that most likely means that the super server wasn't properly configured on the VNC server computer. Review your xinetd configuration, and try restarting the super server. It's also possible that a firewall is blocking access to the VNC server computer.
  • If the VNC client launches and connects to the server but all you see is a gray screen with a cursor that you can move around, the problem is probably with the XDMCP server configuration. Review the settings described earlier, and re-launch the XDMCP server.
  • As a general troubleshooting technique, check your log files. You might need to search all the log files in /var/log for references to xinetd, your XDMCP server, and your VNC server.

VNC security concerns

RFB is not a secure protocol; most VNC clients and servers don't encrypt their data. (VNC does encrypt its own passwords, but the method described here doesn't use these passwords.) Be cautious about where and how you deploy VNC. If you want to use VNC over an unsecured network, you have three choices:

  • Use a virtual private network (VPN).
  • Tunnel the protocol over SSH.
  • Use a VNC variant that supports encryption, such as TigerVNC, which enables Transport Layer Security encryption.

Enabling VNC logins as described in this article opens at least two ports (the VNC port and the XDMCP port) to the outside world. You might want to restrict both ports with firewall rules to minimize the risk of abuse. Note that the XDMCP port (UDP port 177) need only be opened to localhost, so its firewall rule can be quite restrictive.


Overall, linking VNC and XDMCP is a useful technique to enable remote GUI logins to multiuser Linux computers. This method has advantages over using XDMCP directly in cross-platform environments or if working around firewall or NAT issues could be a problem. It's beneficial over more common direct VNC approaches on multiuser computers. If you use this method, be sure to consider the security issues. Be prepared to set up firewall rules to restrict unwanted outside access, and use encryption if your transfers traverse untrusted networks.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=Open source, Linux
ArticleTitle=Enable multiuser logins with VNC