Building a Virtual Desktop Server

Every so often the business world cycles through the idea that end-users don't need computers on their desk and they can use thin clients instead. Inevitably, this fails because the user experience is inadequate. Powerful applications won't run very well or at all. This can include those big Excel spreadsheets that finance people need to use. Even when things do run, the screen updates horribly slowly. So, in the end, everyone has a desktop or laptop back.

However, the virtual desktop doesn't quite die because it still has some uses. System administrators like them for remote management of servers. They can be adapted to function as a sort of remote connection for end-users who are outside the office but don't have a company issued laptop. The technology that makes virtual desktops work is used by help desk staff for remote control of end-user computer. There are many edge cases that keep the technology alive.

Since everything that will be used in this process is not a part of the core operating system, these instruction should work with very little modification on almost any UNIX or UNIX like operating systems. The testing and quoted configurations in this journal entry are from FreeBSD 10.2.

Overview

It is common practice in the UNIX world to use VNC as a remote desktop client for UNIX systems running X11 where the client computer does not have an X11 server installed. It is even further common practice to tunnel the VNC traffic through ssh. This is so common that there is a modified version of the TightVNC client with the SSH capabilities built in (called ssvnc). This standard identifies the specific packages and configuration needed to support a multi-user environment with SSH, VNC, and XDM.

• VNC run through inetd. Allows for up to 64 dynamically assigned virtual desktops without VNC screen sharing.
• XDM runs as a daemon through the rc system. The server does not need to have a GUI enable or an X11 server installed.
• The VNC password must be shared BUT users are still required authenticate individually.
• Two-factor authentication and network session security are provided by SSH.

Caveats

With this configuration, a user is able to log-in using SSH to the command-line interface and bypass the XDM login screen. However, the user did have to authenticate the ssh connection using certificates. If there is a passphrase on the certificate, then the user still performed two-factor authentication. This may be consider as flexibility provided to users who are comfortable with the UNIX command prompt while not hindering users who are not as comfortable.

Bugs

1. When the system first boots, it can take several seconds for inetd to fully start-up. This may result in the system appearing to be down or non-responsive when connecting immediately after startup. Wait a few seconds and try again.
2. The OSX VNC client (called Screen Sharing) does not gracefully exit. This can result in the XDM daemon delaying reset for the affected desktop. When this happens the login screen will not be presented to the end-user for several seconds (until Xvnc attempts to re-try the query). The easiest solution is to advise users to re-try connecting if they fail to get a login prompt.
3. The XDM and TightVNC binary packages for FreeBSD do not identify all pre-requisites needed for those packages to function fully. A list of the missing packages is identified in this document.
4. The SSH match group section (at the bottom) has not been tested. It may not function as intended with this setup.

Setup

The following packages must be installed. All are available a pre-built binaries in the FreeBSD package repository.

Pre-requisites Packages

• xrdb - a prerequisite of VNC that is not identified in the VNC server package.
• xset - a prerequisite of VNC that is not identified in the VNC server package.
• sessreg - a prerequisite to XDM that is not identified by the package.
• xorg-fonts - pre-requisite of XDM that is not identified in the package.
• xsetroot - optional: used to make the login desktop look nicer.
• xterm - optional: prerequisites of the VNC server however, that functionality is not used in this setup.
• twm - optional: prerequisites of the VNC server however, that functionality is not used in this setup.
• xlsfonts - optional: helps with debugging font problems.
• xfotnsel - optional: helps with debugging font problems.

Other packages will get installed automatically as pre-requisites of the main packages. The ones listed above should be but aren't by default.

Packages to Install

• xdm - the X11 Display Manger used to present the user with a login screen.
• tightvnc - the Virtual Network Client that provides a remote desktop display (since remote X11 is not always available).

Pre-requisite Services

A working SSH server must be installed and running on the server. It needs to be configured to allow port forwarding from clients. The default SSH server included with FreeBSD is configured this way and should be enabled in the rc subsystem already (if not, add the line sshd_enable="YES").

Configuration

VNC and Inetd

In order for OSX (Apple Mac users) to connect, the VNC server must present a password. We will therefore create a simple VNC password file to be used. This password will need to be shared among all users. It is not for security purposes, it is used due to a technical limitation. DO NOT USE THE ROOT PASSWORD or your own. If in doubt, use the word "password". The following steps are used to create this password:

vncpasswd
cp ~/.vnc/passwd /etc/vncpasswd.nobody
chmod 0600 /etc/vncpasswd.nobody
chown nobody /etc/vncpasswd.nobody

/etc/inetd.conf

By running the VNC server through inetd, we are able to dynamically assign X11 desktops to users as they connect. This creates an service very similar to a Citrix VDI solution.

vnc stream tcp nowait  nobody /usr/local/bin/Xvnc Xvnc -inetd -query localhost -localhost -once -desktop VictorVM -geometry 1280x720  -depth 24 -rfbauth /etc/vncpasswd.nobody

All users will have a screen size of 1280x720 as defined by the -geometry parameter. This may be changed but it must be the same for all users. Note that the most common laptop screen resolution is currently 1366x768. Higher values may cause problems for some users.

XDM

The pre-packaged XDM is poorly set-up and not intended to operate the way we are setting it up, as such there are several steps that must be taken.

/usr/local/etc/rc.d/xdm

Normally xdm is run from /etc/ttys on virtual terminal 8 but this would require a local graphical console. Instead we will run it as a daemon process. Create a daemon control script for the service manager subsystem. The script should be placed in the file /usr/local/etc/rc.d/xdm, owned by root, and executable by root.

#!/bin/sh

# PROVIDE: xdm
# REQUIRE: DAEMON
# KEYWORDS: shutdown

. /etc/rc.subr

name=xdm
rcvar=xdm_enable
command="/usr/local/bin/xdm"
pidfile="/var/run/xdm.pid"

load_rc_config $name
run_rc_command "$1"

/usr/local/lib/X11/xdm/Xservers

Comment out the last line of the Xservers file to prevent xdm from trying to start a local X server on the console.

# Comment out the local line so that we are only providing XDMCP support
#:0 local /usr/local/bin/X :0 

/usr/local/lib/X11/xdm/Xaccess

Enable the XDMCP listener functionality of xdm. By adding a line to the end of the file:

LISTEN 127.0.0.1

/usr/local/lib/X11/xdm/Xresources

For some reason the default Xresources file attempts to make use of fonts that are not available to XDM when it is run as a daemon. There is probably a way to add those fonts with additional configuration of Xvnc but it is easier to modify this file to make user of fonts that are available. The following are the lines that need to be changed.

xlogin*greetFont: -sony-fixed-medium-r-normal--24-170-100-100-c-120-iso8859-1
xlogin*font:       -sony-fixed-medium-r-normal--16-120-100-100-c-80-iso8859-1
xlogin*promptFont: -sony-fixed-medium-r-normal--16-120-100-100-c-80-iso8859-1
xlogin*failFont: -misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-1
xlogin*greetFace:       Fixed-24
xlogin*face:            Fixed-16
xlogin*promptFace:      Fixed-16
xlogin*failFace:        Fixed-14:bold

Note: in the default file, these lines appear twice and the specific set selected depends on the screen resolution. It is safes to simply change both.

/usr/local/lib/X11/xdm/xdm-config

Comment out the link that disable XDMCP. It should be the last line in the file. It is the resource defined by DisplayManger.requrestPort.

! Comment out this line if you want to manage X terminals with xdm
!DisplayManager.requestPort: 0

/etc/rc.conf

Once everything else is configured, the rc system can be configured to start the daemons on system startup. The following lines should be added to /etc/rc.conf:

inetd_enable="YES" # running VNC server through INETD
xdm_enable="YES" # try to start xdm for the VNC server(s)

End User Desktop Setup

The choice of end-user desktop environment will be very purpose dependent. There are a great many choices available. The setup presented here is intended for basic testing only. A more modern desktop environment should be chosen and configured.

~/.xsession

Each user with X11 (GUI) access should have a .xsession file in his/her home directory. Here is a very basic setup intended for testing only.

#!/bin/sh

xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm

When the window manager (twm) exits, the user is logged out and the XDM login screen should reappear.

Optional: Two-factor Authentication

If this service is to be provided over the Internet, it is advisable to enforce two-factor authentication. This can be achieved by enforcing the user of certificate based authentication for SSH. Note: the two factors are the ssh certificate (something-you-have) and the passphrase on that certificate (something you know). The VNC password and the unix password for xdm are not needed.

/etc/ssh/sshd_config

To enforce the use of certificate authentication with SSH requires some minor changes to the default configuration. The following identifies only the lines that need changing within that file:

# It is strongly advised to not allow direct remote-root login on all publicly facing servers
PermitRootLogin no

# enable RSA and DSA certificate authentication
RSSAuthentication yes
PubkeyAuthentication yes

# prevent ~/.rhosts authentication
IgnoreRhosts yes

# prevent username & password authentication
ChallengeResponseAuthentication no

Since the passphrase on the ssh certificate cannot be technically enforced, it may be desirable to restrict users so that they are only able to use the VNC tunnel. Additions are needed to the sshd_config file:

Match User limited-user
   #AllowTcpForwarding yes
   #X11Forwarding no
   #PermitTunnel no
   #GatewayPorts no
   AllowAgentForwarding no
   PermitOpen localhost:5900
   ForceCommand echo 'This account can only be used for SSH+VNC access.'

A group called 'limited-user' will need to be created and all users that should not have ssh shell access added to that group. Note: This will not prevent the user xterm or other methods of gaining shell access through the GUI provided.

Configuring the Client(s)

OpenSSH and VNC are available for almost every current operating system in use today on desktops, tablets, and smart phones. Several of them have one or both of these included with the operating system.

Connecting from Windows

We will need to install two applications on our Windows desktop: Putty (for SSH) and TightVNC. Windows installers for both are available from their respective websites. Anyone who is attempting to complete the steps outlined in this article should be able to perform the software installation without difficulty.

• Putty for Windows
• TightVNC for Windows

There are alternatives to both Putty and TightVNC some commercial and some free. These are freely available and what I choose to use on Windows.

PortableApps on Windows

PortableApps is a collection of freely available software for Windows that have been configured to be run directly from a USB thumb drive or other portable media. This option is handy because you can load the appropriate applications on to your thumb drive and keep it in your pocket. Thus any available Windows computer that you can run the application from becomes useful as a client for your virtual desktop server.

Connecting from Apple OSX (iMac, Mac Mini, Macbook, and friends)

The SSH and VNC clients are part of the base operating system. No additional software needs to be installed.

Connecting from Apple iOS (iPad and iPhone)

Guess what? There is an app for that. There are in fact many apps for it. This example will use the iSSH app. It may not be the best. It was the first one I ran across that was free, worked, and didn't display ads.

Connecting from Chrome OS (Chromebook)

Although Google tries desperately to hide it from the user, the fact is that Chrome OS is built on Linux and you can simply use ssh X11 tunnelling exactly like it is described in the FreeBSD and Linux section (below). The only hard part is getting to the ssh client.

Connecting from FreeBSD and Linux

FreeBSD and Linux are both UNIX-like operating systems and as such will most likely be using the X-Window System for their graphical user interface. While one could install the TightVNC client and configure the ssh tunnel in the same manner as described in the Apple OSX section, it is probably far less troublesome to simply tunnel the X11 protocol (used by the X-Window System) through the ssh connection directly instead of having the VNC intermediary.

ssh -X remotehostname path/to/application 

That's all there is to it. The -X (that's a capital X) tells SSH to tunnel the X11 protocol. For consistency, the setup and use of the TightVNC client is described below. It would be use when connecting to a MS Windows or Apple OSX server remotely.

What about Android?

I haven't found a decent combination of SSH and VNC that work adequately on Android. The small screen size makes it worse. It is probably best to use the Android phone as a WiFi access point and connect using something with a bigger screen.

Conclusion

It is somewhat ironic that the X Window System can be run on all the client operating systems listed in this article (except perhaps Android). In fact, the software needed is freely available. However, VNC has the advantage that you can install the VNC server on Windows and it's already a part of OSX. VNC has the other advantage that it can be configured to mirror the actual desktop which helps with remote support.

Risk Assessments for System Administrators

Risk assessments are one of those things that system administrators of larger companies are often asked to get involved in. Most system administrators consider this a waste of time that could be better spend keeping the systems running. Even when the system administrators aren’t directly involved in the assessment, they invariably get more work as a result of someone else’s risk assessment.

In this article, I shall attempt to help the system administrators understand why these risk assessments happen and how being involved in a risk assessment can help the system administrator do a better job.

A risk assessment is a formal process, typically carried out by people who sit in an unusual position in the company called IT governance. These people have the odd job of trying to translate corporate management and business need into information technology terms and back again. The risk assessment process itself is fancy formal process meant to identify all the assets of the company and the risks against them. It then takes those lists and sets priorities.

In my opinion, one of the big failings of the process is that most of the formal processes talk about enumerating the technology in terms of systems. The real assets are not the systems but the data in those systems. This article isn’t meant to debate the merits of the risk assessment process, but to help people who get stuck at the end of it better understand the process.

So, step one is to enumerate all the systems (at least those in the target scope of the risk assessment). Step two is to enumerate all the sources of risk to those systems.

How does this help the system administrator? For starters, there are going to be systems on the edges of the “target scope” like unofficial admin systems and old network hardware. An admin that is involved from the start can either down-play or highlight these systems to get them into (or keep them out of) the risk assessment. As part of the risk assessment you have the opportunity to argue for more resources to upgrade/replace those systems or to keep management from noticing them. 

Be careful here. This can backfire. Get an unofficial admin system noticed and it might be taken away instead of replaced. Get it noticed and there might be a lot more work maintaining it once it’s official and needs to go through change control. Keep it hidden and if it becomes the source of a problem you might get in trouble for not identifying it. The trade-offs can be rough.

Next up is risks. Risks are another trouble spot. They can be anything from elite hackers to nearby train tracks. The key to including a particular risk in the risk assessment is two fold. First there needs to be good 3rd party documentation about it. Articles in professional magazines that the management types recognize or white papers published by information security and audit companies. The second is some details that can support how likely this risk is to be a problem. Industry reports of recent events or statistical papers of historical occurrences. Again, sources that management understand are important.

Good sources of material to management are not the same as good sources to technical people. In fact, they are often quite opposite. Wikipedia would not usually be considered good from a management perspective but the sources that the Wikipedia article references might be. Likewise 2600 magazine and wired are not going to be good sources to management. On the other hand, Business Week, the Wall Street Journal, and white papers published by Deloitte, Trustwave, or most of your corporate vendors will be sources that management trusts.

These sources are not an exhaustive list and may not be accurate for all organizations. If you can find out where the management in your organization get their news, that’s a good start.

The key to all of this for the system administrator is to identify risks to specific systems and point them out to the people writing the risk assessment. More risks and risks with a higher likelihood are likely to get a system more attention.

Understand of what went into the risk assessment report helps to understand why management is putting increased focus on some things and less focus on other things. If that key system that keeps everything running smoothly is ignored, there may not be sufficient resources to keep it that way. If a minor system gets too much focus the administration staff may find they are spending too much time on something nobody really cares about.