Remote Support Tools: VNC, SSH Tunneling, and Ad Hoc Screen Sharing

Virtual Network Computing (VNC) is a cross-platform remote desktop protocol that listens on TCP port 5900 and ships the remote screen to your viewer while sending your keyboard and mouse input back. Its two defining traits drive every exam question about it: it works on nearly any operating system (its main advantage over Windows-only Remote Desktop Protocol), and its native traffic is not encrypted — so any VNC session crossing an untrusted network should be wrapped in a Secure Shell (SSH) tunnel or a VPN. For one-off customer help, though, neither VNC nor SSH is the right reach: an ad hoc screen-sharing tool that runs from a session code with nothing permanently installed is the tool of choice.

What VNC is and how it works

VNC uses the Remote Frame Buffer (RFB) protocol. The machine being controlled runs a VNC server; the technician runs a VNC viewer. The server captures the frame buffer — the rendered pixels of the desktop — compresses the regions that changed, and streams them to the viewer. The viewer sends keystrokes and pointer events back. Because RFB deals in pixels rather than Windows-specific display commands, VNC servers and viewers exist for Linux, macOS, Windows, and even embedded systems, and any viewer can generally talk to any server.

Port numbering: the base port is TCP 5900, and each additional display adds its display number — display :1 listens on 5901, display :2 on 5902. On the exam, “VNC” maps to 5900 the same way “RDP” maps to 3389 and “SSH” maps to 22.

Two behavioral differences from RDP matter in the field. VNC shares the console session — the person at the physical machine watches the technician work, which is often exactly what you want in a support call. RDP, by contrast, typically logs the user into their own session and locks the physical console. And VNC needs no special OS edition, while RDP hosting requires Pro or better on Windows.

The encryption problem and the SSH tunnel fix

Classic RFB sends screen data and input events in cleartext, and its password handshake is weak by modern standards. On a LAN you control, that may be acceptable; across the internet it is not — anyone positioned on the path can watch the session or capture credentials.

The standard fix is SSH tunneling, also called SSH port forwarding. SSH gives you an authenticated, encrypted channel on TCP 22, and it can carry other protocols inside that channel. The technician opens an SSH connection to the remote machine (or a jump host in front of it) with a local-forwarding rule such as: forward local port 5901 to the remote machine’s port 5900. Then the VNC viewer connects to localhost:5901 — the tunnel picks the traffic up, encrypts it, carries it over port 22, and delivers it to the VNC server on the far side. The VNC protocol never touches the open internet in the clear, and the firewall only needs SSH exposed instead of 5900.

This pairing is especially natural on Linux workstations, which nearly always run an SSH server already. Some modern VNC implementations add their own Transport Layer Security (TLS) encryption, but the portable, exam-ready answer for “VNC over the internet, securely” is: tunnel it through SSH or run it inside a VPN.

SSH alone is also a remote support tool in its own right — a command-line session for administering Linux and macOS systems where no GUI is needed. The tunnel trick is just SSH doing double duty as transport.

Ad hoc screen sharing: support without an install

A different support situation calls for a different tool entirely. A customer calls the help desk once, needs their printer fixed, and will likely never call again. Installing a VNC server on their home PC — or any permanent management agent — is overkill and a liability: it’s standing remote-access software left behind on a machine you don’t manage.

Ad hoc (on-demand) screen-sharing tools exist for exactly this. The customer downloads or launches a small support client, reads the technician a one-time session ID and PIN, and the tool brokers an encrypted connection through the vendor’s cloud service. Because both ends dial out to the broker, the session traverses home routers and firewalls with no port forwarding — a real advantage, since forwarding ports like 5900 through a home router is exactly the kind of exposure SOHO router hardening warns against — and because nothing is permanently installed or left listening, access ends when the session ends. The customer stays in control — they can watch everything and kill the session at any time. Talking a non-technical caller through the session code calmly is a soft skill of its own, covered in customer communication for technicians.

	VNC	SSH	Ad hoc screen share
Port	TCP 5900	TCP 22	Outbound via vendor broker
Encrypted natively	No (classic RFB)	Yes	Yes
Interface	Full GUI desktop	Command line	Full GUI desktop
Setup on remote end	Server installed and listening	SSH daemon enabled	One-time client, session code
Best fit	Recurring GUI access to managed machines	Linux/macOS admin, tunneling	One-time customer support

The persistent-agent counterpart — where an agent is deliberately pre-installed on every managed endpoint for monitoring and unattended access — is Remote Monitoring and Management (RMM), covered in RMM and third-party remote access.

Choosing among them on a service call

Ask three questions. Is this machine one you manage long-term, or a one-time contact? One-time means ad hoc screen share. Does the task need a GUI, or is it configuration and log work on a Unix-like system? Command-line work means SSH. Will graphical access to a managed non-Windows machine recur? That’s VNC territory — installed deliberately, firewalled, and always tunneled or VPN-wrapped if sessions leave the local network.

How the 220-1202 exam tests this

• A straight port-recall item: which TCP port is associated with VNC — 5900, distinguished from RDP’s 3389 and SSH’s 22.
• A scenario where a technician must use VNC across the internet and is worried about the unencrypted traffic, asking for the BEST way to secure it — the answer pattern is tunneling the VNC session through SSH (or a VPN), not switching ports or relying on the VNC password.
• A one-time customer-support scenario (home user, single incident, no pre-installed agent allowed) asking which tool type fits — ad hoc/on-demand screen sharing, not VNC, not RDP, not an RMM agent.
• A tool-matching item mixing VNC, RDP, SSH, and screen-share options against use cases — testing that you match cross-platform GUI vs. Windows GUI vs. command line vs. one-off support.

Remote access tools fall under the Operational Procedures domain — the full 220-1202 study guide explains what else that domain covers and how much it counts, and practice questions turn the tool-matching into reflex.

Quick reference

• VNC = cross-platform remote desktop on TCP 5900 (display :N listens on 5900 + N), using the RFB protocol.
• Classic VNC traffic is unencrypted — never run it bare across untrusted networks.
• Secure it by tunneling through SSH (port 22) or running it inside a VPN; the viewer then connects to the forwarded localhost port.
• VNC shares the console screen with the local user; RDP (TCP 3389) opens a separate session and is Windows-native.
• SSH is the command-line remote-admin tool for Linux/macOS and doubles as the encryption wrapper for other protocols.
• Ad hoc screen-sharing tools use one-time session codes through an outbound cloud broker — no open ports, no installed agent, access dies with the session.
• One-time customer help → ad hoc tool; recurring managed GUI access → VNC/RDP; fleet-wide unattended management → RMM.