Remote Desktop Concepts
Chapter 1 — Remote Desktop Concepts
SSH gives you a terminal — text in, text out. Remote desktop goes further: it lets you see and interact with a full graphical desktop on a remote machine as if you were sitting in front of it. Mouse movements, window clicks, keyboard input — all transmitted across the network in real time.
Two protocols dominate the field: RDP (Remote Desktop Protocol, developed by Microsoft) and VNC (Virtual Network Computing, an open standard). They solve the same problem in quite different ways, with different performance characteristics, security models, and ideal use cases.
How Remote Desktop Works
At its core, every remote desktop protocol follows the same pattern: the server captures what's on screen, compresses and encodes it, and sends it to the client. The client displays it and sends back user input (mouse, keyboard). The differences between protocols lie in how they do each step.
Your machine
RDP / VNC Client
→mouse & keyboard input
Network
TCP connection
(encrypted or plain)
(encrypted or plain)
→screen updates
Remote machine
RDP / VNC Server
RDP vs VNC — The Two Protocols
RDP
Remote Desktop Protocol · Microsoft · Port 3389
Developed by
Microsoft (1998)
How it works
Sends rendering instructions (draw this rectangle, render this font) — not raw pixel data
Performance
Excellent — very efficient on slow connections
Encryption
Built-in TLS — encrypted by default
Platforms
Native on Windows; clients available everywhere; server needs xRDP on Linux
Sessions
Creates a separate session — doesn't show what's on the physical screen
VNC
Virtual Network Computing · Open standard · Port 5900
Developed by
Olivetti Research Lab (1998), now open standard
How it works
Sends raw pixel data (screenshots of changed regions) — framebuffer sharing
Performance
Heavier — pixel data is large; better on fast local networks
Encryption
NOT encrypted by default — must tunnel through SSH
Platforms
Truly cross-platform — Linux, macOS, Windows, Raspberry Pi
Sessions
Mirrors the physical screen — you see exactly what's on the monitor
The key architectural difference: RDP sends drawing commands
("render a button here, draw this text there") and the client reconstructs
the UI locally. VNC sends raw pixel snapshots of what changed on screen.
RDP is more like a shared app; VNC is more like a video feed of the screen.
This is why RDP is faster over the internet and VNC is better for seeing
exactly what's physically on the monitor.
Side-by-Side Comparison
| Feature | RDP | VNC |
|---|---|---|
| Default port | 3389 | 5900 (5901, 5902… per display) |
| Encryption | Built-in TLS | None by default — use SSH tunnel |
| Performance | Excellent on slow links | Heavier — needs fast connection |
| Linux server | Needs xRDP installed | Native (TigerVNC, RealVNC etc.) |
| Windows server | Built in (Pro/Server editions) | Third-party software needed |
| Screen mirroring | Separate session only | Mirrors physical display |
| Multi-monitor | Supported natively | Limited / implementation-dependent |
| Audio redirection | Supported | Limited |
| File transfer | Built in (drive redirection) | Not built in — use SFTP separately |
| Cross-platform clients | Good — many available | Excellent — universal standard |
| Raspberry Pi / headless Linux | Possible but extra setup | Ideal use case |
Use Cases — Which Protocol Fits
💼
Accessing your work Windows PC from home
Full desktop access to a PC that stays at the office, with file access, audio, clipboard sync.
RDP — built in, fast, encrypted
🍓
GUI access to a Raspberry Pi
Your Pi is headless (no monitor). You want to see its desktop without plugging in a screen.
VNC — mirrors the display, works great on LAN
🖥️
Helping a family member with their PC
You need to see exactly what's on their screen — the same view they have.
VNC — screen mirror. Or TeamViewer/AnyDesk for simplicity
🐧
Linux desktop from Windows
Accessing a Debian or Ubuntu desktop remotely from a Windows machine.
Either — xRDP for performance, VNC for simplicity
🔧
Remote server administration with a GUI
Running a GUI tool (database manager, file manager) on a headless server.
RDP via xRDP — cleaner sessions, better performance
🌐
Access over the internet
Connecting to a machine from outside your home network — over a VPN or SSH tunnel.
RDP preferred — lighter bandwidth, built-in encryption
Security Considerations
Remote desktop is one of the most attacked surfaces on the internet. A Windows machine with RDP exposed on port 3389 will be hit by automated brute-force bots within minutes of going online. VNC without a tunnel is even worse — it has no built-in encryption and weak default authentication. These protocols were designed for local networks first.
Critical
Exposing RDP directly to the internet
Port 3389 open on your firewall invites constant automated brute-force attacks. BlueKeep (CVE-2019-0708) and DejaBlue are examples of critical RDP vulnerabilities. Never expose it publicly without a VPN or reverse tunnel.
Critical
VNC without SSH tunnel
Plain VNC sends pixel data unencrypted. Passwords are weakly hashed. Anyone on the same network can intercept the session. Always tunnel VNC through SSH — covered in Chapter 6.
High
Weak passwords
Both RDP and VNC are targeted by credential-stuffing attacks. Use strong, unique passwords and — where possible — restrict access to known IPs via firewall rules.
High
Unpatched servers
RDP has a history of critical remote-code-execution vulnerabilities. Keep Windows and xRDP updated. Enable Windows Update and don't defer security patches on machines with RDP enabled.
Medium
No MFA on RDP
Windows RDP supports Network Level Authentication (NLA) which requires credentials before the session starts — harder to exploit. Enable NLA and consider adding MFA via a VPN layer.
Medium
Leaving sessions open
An unlocked remote desktop session is a wide-open door. Configure auto-lock on inactivity and disconnect sessions when not in use. On Linux, VNC servers should be stopped when not needed.
The golden rule: Never expose RDP (port 3389) or VNC
(port 5900) directly to the internet. Always access them through a
VPN, an SSH tunnel, or a reverse proxy with strong authentication in
front. This course covers both approaches in later chapters.
What This Course Covers
Eight chapters covering both protocols across the platforms you're most likely to encounter:
- Chapters 2–4 — RDP in depth: enabling it on Windows, connecting from Linux and from Windows, multi-monitor and audio settings
- Chapter 5 — xRDP: bringing RDP to Linux (Debian/Ubuntu)
- Chapter 6 — VNC: TigerVNC setup and the essential SSH tunnel
- Chapter 7 — Alternatives: NoMachine, AnyDesk, TeamViewer — when the classics aren't the right tool
- Chapter 8 — Getting through firewalls: SSH tunnels, Cloudflare Tunnel, performance tuning on slow connections