Enable multiuser logins with VNC

Help your users access a multiuser Linux system from anywhere

Virtual Network Computing (VNC) is a popular tool for providing remote access to computers. The usual VNC configuration is optimized for single-user workstations, and logging in to the VNC port directly accesses a single user's desktop. This configuration is awkward on multiuser computers, however. Fortunately, you have an alternative. By linking VNC to a Linux computer's normal X Display Manager Control Protocol (XDMCP) server, accessing the VNC port enables users to provide their user names and passwords, thereby enabling a single VNC server instance to handle multiple user logins.

Share:

Roderick W. Smith, Consultant and author

Photo of Roderick W. SmithRoderick W. Smith is a consultant and author of more than a dozen books on UNIX and Linux, including The Definitive Guide to Samba 3, Linux in a Windows World, and Linux Professional Institute Certification Study Guide. He is also the author of the GPT fdisk partitioning software. He currently resides in Woonsocket, Rhode Island, and you can reach him at rodsmith@rodsbooks.com.



24 April 2012

Also available in Chinese Russian Japanese Vietnamese Portuguese

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

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

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

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. (Resources 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 \
                           /var/lib/xdm/authdir/authfiles/A:0-pp4shb
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
GDM/etc/X11/gdm/custom.conf[xdmcp]enable=true
KDM/usr/share/kde4/config/kdm/kdmrc[Xdmcp]Enable=true
LightDM/etc/lightdm/lightdm.conf[XDMCPServer]enabled=true

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:

[Xdmcp]
Enable=true

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:

DISPLAYMANAGER_REMOTE_ACCESS="no"

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:

vncviewer remotename

. . . 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 remotename: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

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.


Conclusion

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.

Resources

Learn

Get products and technologies

  • TightVNC ships with many distributions, or you can obtain it from the TightVNC website.
  • TigerVNC is a fork of TightVNC that's available with some distributions, or you can obtain it from the TigerVNC website. It's notable in that it includes extensions that support encrypted connections.
  • RealVNC is a company founded by some of the original VNC developers. It offers both free and commercial versions of its VNC implementation.
  • Access IBM trial software (available for download or on DVD) and innovate in your next open source development project using software especially for developers.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Open source on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Open source, Linux
ArticleID=811292
ArticleTitle=Enable multiuser logins with VNC
publish-date=04242012