Windows administrators have three realistic remote access protocols: RDP for graphical sessions, VNC/ RFB for console-level access, and SSH for text and automation. They are not competitors so much as different layers — most well-built servers use all three. This article compares them on transport, encryption, authentication, bandwidth, and licensing so you can pick deliberately instead of by habit.
How Each Protocol Actually Works
RDP does not transmit pixels by default. It transmits drawing primitives — “draw this glyph here”, “update this rectangle” — and caches bitmaps persistently on both ends. That is why RDP feels interactive over connections where a pixel-streaming protocol would be unusable.
VNC (RFB) transmits framebuffer updates. It is protocol-agnostic and works even at a pre-boot console, but it moves far more data and, unless tunnelled, is unencrypted. Its strength is being able to see a machine when there is no operating system session to log into.
SSH gives you a command channel, encrypted and authenticated by key. Windows ships an OpenSSH Server feature, and it is the right tool for anything scriptable: file transfer, service restarts, log tailing, and remote PowerShell.
Head-to-Head Comparison
| Attribute | RDP | VNC (RFB) | SSH |
|---|---|---|---|
| Default port | TCP 3389 (UDP 3389 for RDP-UDP) | TCP 5900 | TCP 22 |
| Graphical desktop | Yes, full | Yes, framebuffer | No |
| Encryption | TLS + CredSSP/NLA | None by default; needs SSH/TLS tunnel | Always (AES, ChaCha20) |
| Authentication | Password, smart card, NLA pre-auth | Password (often single, weak) | Public key + password + MFA possible |
| Multi-user / concurrent sessions | Yes on Server SKUs; session brokering | Typically one shared framebuffer | Yes, one channel per connection |
| Clipboard & drive redirection | Native | Partial, add-on dependent | Via SCP/SFTP, not clipboard |
| Typical bandwidth | 50–300 kbps tuned; 2–5 Mbps full-motion | 1–10 Mbps at low colour depth | Under 50 kbps |
| Works pre-boot / in BIOS | No | Yes (KVM-over-IP consoles) | No |
| Automation friendly | Limited (UI automation only) | Poor | Excellent |
| Licence cost | Included with Windows Server | Open and free (TigerVNC, TightVNC) | Open and free (OpenSSH) |
RDP in Practice
:: Client side
mstsc /v:203.0.113.10:3389
:: Server side: confirm enabled, NLA on, encryption level 3 (High)
Set-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0
Set-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 1
Set-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name MinEncryptionLevel -Value 3Everything you need is already installed and licensed. The trade-offs are that RDP has no pre-boot visibility, a single compromised password is enough to reach a full desktop, and leaving 3389 open to the internet invites continuous brute-force traffic.
VNC in Practice
:: Never expose 5900 directly. Bind to loopback and tunnel:
:: On the server, configure TightVNC/TigerVNC to listen on 127.0.0.1:5900
:: From your workstation:
ssh -L 5900:127.0.0.1:5900 [email protected]
:: Then point the VNC viewer at localhost:5900VNC’s genuine use case on Windows is the hypervisor console: when the VM is stuck at a boot screen or RDP’s own service is broken, a VNC/KVM-over-IP console is the only way in. As a daily administration channel it is slower, less secure by default, and weaker at multi-user work than RDP.
SSH on Windows Server
:: Install the built-in OpenSSH Server (Windows Server 2019+)
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic
:: Set the default shell to PowerShell for non-interactive use
New-ItemProperty -Path 'HKLM:\SOFTWARE\OpenSSH' -Name DefaultShell `
-Value 'C:\Program Files\PowerShell\7\pwsh.exe' -PropertyType String -Force
:: Key-based login: drop the public key into the administrators' file
:: C:\ProgramData\ssh\administrators_authorized_keys (ACL: SYSTEM + Administrators only)That last step is the one people get wrong. On Windows, keys for members of the Administrators group must live in administrators_authorized_keys, not the per-user file, and the file’s ACL must be restricted or sshd will silently refuse the key.
:: Remote administration without a desktop session
ssh [email protected] "Get-Service W3SVC"
scp .\deploy.zip [email protected]:C:/inetpub/staging/
ssh [email protected] "Restart-Service W3SVC"Hybrid Setups Are the Norm
The strongest configuration tunnels RDP through SSH so port 3389 never faces the internet:
:: On the server, restrict RDP to loopback
New-NetFirewallRule -DisplayName 'RDP loopback only' -Direction Inbound -Protocol TCP -LocalPort 3389 `
-RemoteAddress 127.0.0.1 -Action Allow
Set-NetFirewallRule -DisplayName 'Remote Desktop - User Mode (TCP-In)' -Enabled False
:: On your workstation, open a tunnel then connect mstsc to localhost
ssh -L 3389:127.0.0.1:3389 [email protected]
mstsc /v:127.0.0.1:3389Now the only exposed service is SSH, which is authenticated by key rather than by a password that a botnet can guess. The RDP traffic is encrypted twice, and brute-force noise drops to zero because there is no port 3389 to scan.
Decision Matrix
| Task | Best protocol | Reason |
|---|---|---|
| Interactive GUI work, Office, browsers | RDP | Fast, licensed, redirects clipboard and drives |
| Bulk file transfer | SSH (SCP/SFTP) | Scriptable, resumable, encrypted |
| Repeatable configuration changes | SSH + PowerShell | Idempotent, loggable, no UI |
| Recovering a VM that will not boot | VNC / KVM console | Only option pre-OS |
| Multiple admins on one server | RDP sessions or RDP Gateway | Session isolation and brokering |
| Reaching a server across an untrusted network | SSH tunnel to RDP | Single hardened entry point |
| Monitoring and log collection | SSH / WinRM | Text output, easily parsed |
Hardening Checklist for All Three
- Enable NLA on RDP and require TLS with a minimum encryption level of High.
- Never expose VNC port 5900; bind to loopback and tunnel it.
- Disable SSH password authentication once keys are working:
PasswordAuthentication no. - Rate-limit or fail2ban-style block repeated authentication failures.
- Use a non-default port only as noise reduction — never as the security control.
- Enable account lockout policies so password spraying cannot run indefinitely.
- Log successful and failed logons (Event IDs 4624 and 4625) and alert on spikes.
Bottom Line
Use RDP for graphical work, SSH for anything you would otherwise do twice by hand, and VNC only for out-of-band console recovery. If you tunnel RDP over SSH and disable password authentication on both, you get a server that is comfortable to use and effectively invisible to automated attackers. For the wider context of running this kind of server, windows-vps.org covers remote desktop administration on hosted Windows machines end to end.
