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.
OverviewIt 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.
CaveatsWith 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.
SetupThe following packages must be installed. All are available a pre-built binaries in the FreeBSD package repository.
Packages to Install
VNC and Inetd
vncpasswd cp ~/.vnc/passwd /etc/vncpasswd.nobody chmod 0600 /etc/vncpasswd.nobody chown nobody /etc/vncpasswd.nobody
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
#!/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"
# Comment out the local line so that we are only providing XDMCP support #:0 local /usr/local/bin/X :0
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
! Comment out this line if you want to manage X terminals with xdm !DisplayManager.requestPort: 0
inetd_enable="YES" # running VNC server through INETD xdm_enable="YES" # try to start xdm for the VNC server(s)
End User Desktop Setup
#!/bin/sh xrdb $HOME/.Xresources xsetroot -solid grey xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & twm
Optional: Two-factor Authentication
# 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
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.
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.