Tightvnc, Chicken of the VNC

Getting Started with TightVNC and Chicken of the VNC

Virtual Network Computing, or VNC, lets you view and control a desktop on a remote machine as if you were sitting right in front of it. It works across Windows, macOS, Linux, and many other operating systems, making it a practical alternative to Windows Terminal Services or PC‑Anywhere when you need a license‑free solution that also serves Unix‑style servers.

The original VNC code came from an AT&T research project. Today the primary source of that code lives at TightVNC. TightVNC keeps the same protocol but adds a tighter, loss‑less compression algorithm that speeds up the connection over slower links.

When this article refers to TightVNC, the intent is to illustrate key ideas that work with any VNC implementation. The same concepts apply to the original RealVNC, UltraVNC, or the open‑source TigerVNC. A particular implementation only changes the setup steps and the features exposed in its configuration menus.

Choosing a viewer is as important as choosing a server. I once ran the standard vncviewer that ships with Linux distributions and discovered that it mis‑rendered a Windows desktop on a remote machine. Switching to the macOS client tightvnc.com and run it. On macOS, the Chicken of the VNC package can be obtained from the same sourceforge link. On Linux, most package managers ship TightVNC; for example, on Debian‑based systems you can install it with sudo apt install tightvncserver. Once installed, launch vncserver to start a new session.

The first time you run vncserver it will prompt you for a password. This password is shared by all VNC sessions started by the same user. You can change it later with the vncpasswd utility. For a quick session on a headless server, the default command starts a tiny window manager called TWM along with an Xterm. If you prefer a full desktop, you must modify the startup script as described below.

Editing the startup file is a common requirement. Create or edit the file ~/.vnc/xstartup so that it contains a single line pointing to the system’s X initialization script. For instance, on many Linux distributions you can use: /etc/X11/xinit/xinitrc &. Then create a file called ~/.vnc/.xsession and add the command that launches your preferred desktop environment, such as /usr/bin/startkde for KDE or /usr/bin/startxfce4 for Xfce. After saving these files, restart the VNC server to see the full desktop appear.

Some users prefer a login dialog on the client side, which is possible when the server is configured to use XDMCP. While the basic TightVNC setup does not expose this feature by default, you can tweak the XDMCP settings in the /etc/vnc/xstartup file or use a separate XDMCP daemon. The process is more involved, so it’s usually reserved for advanced deployments.

Connecting from a Windows machine to a Linux server is as simple as launching the TightVNC viewer, typing the server’s hostname or IP address followed by the display number (e.g., 192.168.1.50:1), and entering the password. The first connection will render the KDE desktop you configured. If you encounter latency, try selecting the “High Speed” compression level in the viewer options. TightVNC’s compression is tuned for both high‑bandwidth and low‑bandwidth environments.

When working with multiple machines, it’s useful to remember that each VNC session is independent. The server assigns a display number and the client connects to that number. If you open two separate sessions on the same host, the second will get display :2, and the two will run in parallel. This flexibility is one of VNC’s biggest strengths for collaborative work.

In summary, TightVNC provides a fast, flexible, and cross‑platform way to share desktops. The Chicken of the VNC client makes it accessible on macOS, and a few simple configuration tweaks allow you to run a full desktop environment on a Linux server. The real power comes from the protocol’s simplicity, which keeps the implementation lightweight yet capable of handling a wide range of use cases.

Multiuser Scenarios, Performance, and Security Considerations

On Unix‑like systems, the VNC server is designed to run per‑user, not per‑desktop. That means a single machine can host multiple independent sessions, each owned by a different user. For example, on a shared Linux box I can start one VNC server as root and another as the regular user apl. From a Windows 98 workstation I can connect to the root server, while a MacBook runs the apl session. Each connection sees the desktop that belongs to the user who started the server, not the physical display attached to the machine.

Because the server creates a separate login session, you can have several users connected to the same host at once. This is ideal for training, demonstrations, or remote support. If I open three separate VNC clients to the apl session, all three view the same screen. Any key press or mouse movement from one client propagates to the others in real time. The effect is exactly the same as a shared desktop session in Microsoft’s NetMeeting, but with no licensing cost.

Each Unix user can start multiple VNC servers. The first time a user runs vncserver, the password prompt creates a key file in ~/.vnc/passwd that protects all subsequent sessions for that user. Subsequent servers automatically reuse that password. To change it, run vncpasswd from the same user account. The session count increments automatically: the first server gets display :1, the next :2, and so on. No two sessions share a display number, so they can run simultaneously without conflict.

Windows behaves differently. The TightVNC server on Windows attaches itself to the currently logged‑in desktop. When you connect, you see exactly what the local user sees. If you run a second instance of the server on the same machine, it will still try to use the same desktop, so the connection is essentially a duplicate view. Because Windows XP does not support true concurrent logins, the only session that can be viewed is the one that is currently active. If you switch users or lock the screen, the VNC session will drop to black and can’t be re‑established until the original user logs back in.

Security is a common pitfall with VNC. The protocol transmits both screen data and keyboard/mouse events unencrypted unless you add a wrapper. The simplest and most effective method is to tunnel the VNC connection over SSH. On the client side, run ssh -L 5901:localhost:5901 user@server and then point your VNC viewer at localhost:5901. This protects the traffic from eavesdropping on a public network. If you need to expose VNC over the internet, place it behind a firewall that allows only trusted IP addresses.

In TightVNC you can enable optional encryption within the protocol itself, though it is less robust than an SSH tunnel. The encryption key is derived from the user password, so a strong password is essential. TightVNC’s “Encrypted connection” setting forces the client and server to negotiate an encryption handshake before any screen data is sent. Even though it adds overhead, it can be useful on a local network where SSH is unavailable.

Besides TightVNC, other clients can complement the experience. UltraVNC on Windows provides a built‑in chat feature and file transfer capability. On Linux, TigerVNC offers improved performance and a more modern code base. Choosing the right client can solve display or performance quirks that arise on specific platforms.

Typical office scenarios benefit from VNC’s flexibility. I can work from my laptop and open QuickBooks on my wife’s Windows computer without walking over to her desk. She can see my Outlook calendar on her Mac without logging into my machine. Because each VNC session is isolated, the two of us can work on separate tasks without interfering with each other’s workflows.

Running VNC in a controlled environment also means you can limit exposure. Use /etc/hosts.allow and /etc/hosts.deny to restrict which hosts may connect to the server. Combine that with the firewall rules you already have for other services, and you’ll have a tightly scoped remote‑desktop solution that’s both functional and secure.

In practice, the combination of TightVNC on the server side and Chicken of the VNC on macOS, or any other lightweight client on Windows, gives you a reliable cross‑platform remote‑desktop tool. Whether you’re running a single user session on a home lab or multiple sessions on a shared server, the same configuration principles apply. Just remember to keep the passwords strong, use an SSH tunnel if you’re crossing untrusted networks, and test your client before deploying it to others.