MultiVNC: an SSH-enabled VNC viewer that can also serve connections

The transport is the reason this client exists

MultiVNC is a VNC client whose most consequential decision is not the rendering but the transport. The client can open a remote framebuffer session through an SSH tunnel, authenticated with either a password or a private key, so the VNC server never has to be exposed on the network. The desktop build is a C++ application built on LibVNCClient with a wxWidgets interface, running on Unix, Mac OS X and Windows. A separate Android client exists as its own subdirectory with its own release numbering.

That combination puts the project in a narrow lane. It is for the person who already has SSH access to a machine and wants a graphical session over that same channel: administrators checking a console, developers running a desktop on a remote Linux box, or lab staff working with instruments that expose VNC behind a bastion.

The feature list is split along client lines. The transport and discovery features, namely TLS, SSH tunnelling, ZeroConf discovery, UltraVNC Repeater and framebuffer resize, are described as applying to the project as a whole. The rest, tabs, listen mode, macro recording, multi-sync input, the X11 pointer edge trick and statistics, are listed as desktop-only features. The distinction matters when you decide whether a feature you need exists on the platform you actually deploy to.

The project ships under GPL-3.0, with a COPYING file at the repository root and dependencies that are themselves permissively licensed open source. Nothing in the client turns your machine into a general-purpose remote desktop service, and the README does not add redistribution notes beyond the licence text.

Building the desktop client with CMake, Conan and submodules

The desktop client is a CMake project that vendors its dependencies as git submodules. The repository root carries a .gitmodules file, a conanfile.py, a CMakeLists.txt and a flatpak directory, and the vendored trees include libvncserver, libsshtunnel and libwxservdisc. Getting those in place is the first step after cloning, and the README gives exactly one command for it:

   git submodule update --init

On Linux, CMake drives the build directly and cpack produces the package, here in debug mode as a .deb:

   mkdir build
   cd build
   cmake .. -DCMAKE_BUILD_TYPE=Debug
   cmake --build .
   cpack

On MacOS and Windows the same sequence is preceded by a Conan install that resolves the toolchain and writes it into the build folder:

   conan install . --output-folder=build --build=missing -s build_type=Debug
   cd build
   cmake .. -DCMAKE_TOOLCHAIN_FILE="conan_toolchain.cmake" -DCMAKE_BUILD_TYPE=Debug
   cmake --build .
   cpack

Read those instructions as a developer quickstart rather than a release guide. Every flag selects Debug, and the README does not describe a Release variant or name the individual CPack targets. If you want a desktop client for daily use, the project points at Flathub for Linux and the Mac App Store for macOS. For artifacts built from the master branch, it points at the list of CI runs, where you select the last successful run and download the artifact you need.

The Android build is not covered here. Its instructions live in the Android README inside the android directory, and its dependency model is separate.

Listen mode turns the viewer into a reverse VNC server

MultiVNC can take the other side of the connection. The README describes a listen mode, that is reverse VNC, and notes that the tabbed interface makes it possible to listen for and serve several incoming connections at once. A laptop running the client can therefore act as a VNC server for any other client that speaks the protocol.

This is the feature that separates the project from a plain viewer, and it is also the one that carries the most operational weight. Listen mode is where a viewer becomes a network service. It opens a listening socket, it accepts incoming VNC handshakes, and the protection around that socket has to come from whatever the platform provides on top. The README does not document how listen mode is restricted to a particular interface, how incoming connections are authenticated, or whether the socket can be bound to a single address. Anyone planning to expose it should assume an SSH tunnel or a firewall in front, and should check the behaviour of the actual build rather than trust an undocumented default.

The tabbed connection model is the practical reason listen mode and multi-sync input live in the same tool. Several remote framebuffers sit in one process, which is convenient for watching a handful of machines at once and makes the replication features possible, but it also means one process holds every session and every set of credentials at the same time.

Multi-sync input and macro recording fail quietly on uneven machines

The desktop client can record user input as macros and replay them, and it can mirror input directed at one connection to every other open connection. Both save hours when you drive a fleet of identical machines, and both turn destructive the moment the machines differ.

Multi-sync has no notion of intent. A keystroke or click aimed at one target is replicated to the rest, so one mistaken click lands on every tab, on systems where the effect may be hard to undo. The README does not document a confirmation step, a whitelist of connections, or a way to exclude a tab from the replication set. The defensible way to use it is to enable it only across machines that are genuinely interchangeable.

Macro recording inherits the same fragility from the remote side. A recorded sequence of keystrokes and clicks assumes a screen layout, a window arrangement, a focus order and a resolution, none of which a plain input recording captures. The README lists framebuffer resize support as a client feature, but says nothing about macros surviving a resize or a remote session whose layout changes. Treat recorded macros as valid for one specific remote state and re-record when that state changes.

The X11 pointer edge feature belongs to the same category of convenience with a cost. It offers control of the remote side by moving the pointer to the top edge of the screen, and the README credits x2vnc and earlier ideas from x2x and vncviewer. It is tied to X11, so it has no meaning on the MacOS and Windows builds.

MulticastVNC support is marked experimental for a real reason

MulticastVNC appears on the feature list and is labelled experimental in that same list. The label does real work here, because multicast does not behave like a normal VNC connection and the standard library will not do it.

The README points to a modified libvncserver and libvncclient tree hosted under the LibVNC organisation on a branch named multicastvnc, and notes that this is the same library MultiVNC uses internally. In practice the multicast path depends on a fork of the protocol stack rather than the upstream one a normal install pulls in, so anyone building for multicast has to fetch that branch deliberately and know which library ended up in the binary.

There is a hard network requirement on top of that. Multicast only works where the network forwards multicast groups, which rules out most cloud networks, many corporate LANs and typical home routers that isolate clients from each other. A feature unavailable on the networks where a remote viewer is most wanted is worth knowing about before you pick the tool rather than after.

If the requirement is simply to reach a VNC server, the SSH tunnelling path is the documented one and needs no patched dependency.

TLS handles certificates, while ZeroConf discovery adds its own surface

Security handling splits into two layers that deserve separate treatment. On the transport side, the client supports TLS through AnonTLS and VeNCrypt, and the README states that self-signed certificates are supported. That matters in practice because most internal VNC deployments use certificates no client can chain to a public authority, and refusing them would push operators back toward plaintext.

Discovery is a different mechanism. The client can find VNC servers that advertise themselves over ZeroConf, and the repository vendors a libwxservdisc tree for service discovery. That gives a desktop user a list of nearby machines without typing addresses, but it also means the client acts on broadcast announcements arriving from the local network. Whether that is acceptable depends on the segment. On a shared or untrusted network, auto-discovered endpoints are another surface to weigh, and the README does not describe a switch to disable discovery or a way to filter which discovered servers are offered. Check that behaviour on the network you actually run, and treat the SSH tunnel as the path whose behaviour you can reason about.

UltraVNC Repeater support closes the gap for networks that already use a repeater to mediate connections on behalf of many machines, which is a common arrangement for larger deployments.

The Android client is a second product sharing the name

The Android build is not a port of the desktop code. It lives in the android directory, has its own README and its own build steps, and it carries its own version line: AndroidMultiVNC 2.3.4 published on 2026-03-09 and 2.3.3 on 2026-02-20, while the desktop line sits at MultiVNC-0.11.0 from 2026-03-15. Treat the two as separate products that happen to share a name and a repository.

What the Android side changes is the interaction model, not the transport. The README lists import and export of saved connections, virtual mouse buttons with haptic feedback, two-finger swipe gesture recognition, a fast touchpad mode intended for local use, and hardware accelerated OpenGL drawing with zooming. The desktop-only features stay on the desktop: tabs, listen mode, macro recording, multi-sync input and the X11 pointer edge behaviour do not appear in the Android feature list.

Release timing is worth noting as well. All three recent releases are dated February and March 2026, and the last push to the repository was on 2026-10-22, so the branch carries work that has not been packaged into a numbered release. If you want the current state of the code rather than a tagged build, the project points at the CI run list for artifacts built from master.

Editorial conclusion

MultiVNC suits administrators and developers who already hold SSH access to the machine they need to see and want that same channel to carry a graphical session, and it suits lab setups that want a reverse VNC server inside the same client. It does not suit teams that need a hardened multi-user remote desktop with per-user policy, since listen mode documents no authentication of its own, and it does not help on networks where multicast is filtered. Before you commit, verify three things: that the SSH tunnel carries the session end to end in your environment, that listen mode can be bound to an interface you control, and that the build you install matches the numbered release you tested. The repository's last push was on 2026-10-22 while the newest packaged desktop release is 0.11.0 from 2026-03-15, so a CI artifact and a tagged release are not the same thing.

Frequently asked questions

Official sources

1. bk138/multivnc on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases