Prefer SSH for most Ubuntu administration. Add remote desktop only when a complete graphical session, assistance on the current desktop, or a GUI-dependent application is genuinely required. The secure default is a remote-desktop service reachable only through loopback or a controlled private network; SSH, VPN, or an authenticated TLS gateway provides access across networks. Never expose raw VNC to the public Internet.

Table of Contents

1. Choose the technology from the need

Need	Preferred choice	Critical boundary
Commands, files, logs, and port forwarding	OpenSSH	No graphical desktop required
Assist the logged-in GNOME desktop	GNOME Remote Desktop Desktop Sharing (RDP)	Current user consents; verify encryption fingerprint
Log into GNOME on an unattended machine	GNOME Remote Desktop Remote Login (RDP), when supported locally	Different session/port semantics from Desktop Sharing
Independent persistent virtual X11 desktop	TigerVNC/Xvnc with vendor `vncsession`	Dedicated non-root user, localhost, SSH/VPN
Behind CGNAT or unable to accept inbound traffic	Managed VPN, loopback-bound reverse SSH tunnel, or relay	Establish outbound; never publish VNC
Run only one GUI application	Application-native remote mode, SSH forwarding, or job queue	Do not expose a complete desktop

Do not assume VNC is right because the title says “install VNC Server.” Document the user, application, whether the current session is shared, whether a login screen is required, allowed sources, data sensitivity, recovery channel, and stop time first.

2. Read-only inventory before changing anything

These commands do not change configuration. Missing units or programs can report errors; record them as version/desktop differences instead of installing random software or copying an old tutorial.

. /etc/os-release
echo "$NAME $VERSION_ID"
echo "$XDG_CURRENT_DESKTOP"
echo "$XDG_SESSION_TYPE"
loginctl show-session "$XDG_SESSION_ID" -p Type -p Class -p Remote
apt-cache policy gnome-remote-desktop tigervnc-standalone-server openssh-server
command -v grdctl Xvnc Xtigervnc tigervncserver vncsession vncpasswd ssh
systemctl --user status gnome-remote-desktop.service --no-pager
systemctl cat 'tigervncserver@.service'
ss -lntp
sudo ufw status verbose

Also record the graphical session, display manager, listening addresses/ports, firewall/security-group/router rules, existing VPN/tunnels, package origin and version, autostart owner, screen-lock behavior, and a second management path. Evidence must not contain passwords, private keys, session cookies, clipboard contents, or full desktop screenshots.

3. Establish recovery and consent boundaries first

Keep a verified SSH or physical console that does not depend on the remote desktop being changed.
Validate first with an ordinary test user and non-production host; never run a desktop or VNC server as root.
For sharing the current desktop, the local user must know when it starts, who can control it, whether clipboard is shared, and how to disconnect immediately.
Use a remote-desktop credential separate from the Ubuntu login password, email, and every other service. SSH/VPN/gateway also needs its own strong authentication.
Record old unit/config/firewall state and make a permission-restricted backup. Never delete a whole configuration directory to “reinstall.”
Define a maintenance window, idle/connection timeout, approved clients, and rollback operator.

Stop if the only recovery path is the same GUI being tested, the only admin credential cannot be rotated, or the owner of an existing listener is unknown.

4. GNOME RDP: desktop sharing and remote login differ

Current GNOME help separates Desktop Sharing from Remote Login. The former views or controls the current logged-in desktop; the latter logs into a user account remotely. Their ports can differ when both are enabled, so do not hard-code 3389. Use the hostname, port, login details, and encryption fingerprint displayed under Settings ▸ System ▸ Remote Desktop.

Prefer the Settings UI to enable only the needed mode, set a dedicated credential, and compare client/server encryption fingerprints through an independent trusted channel. Never put the password on a grdctl command line, in shell history, a screenshot, or chat. Use CLI only to inspect features supported by the installed version:

grdctl --help
systemctl --user cat gnome-remote-desktop.service
systemctl --user status gnome-remote-desktop.service --no-pager
journalctl --user -u gnome-remote-desktop.service --since today --no-pager

Restrict RDP to a managed VPN, a trusted LAN with an exact firewall allowlist, or an authenticated TLS access boundary. Encryption alone does not justify exposing an administrative desktop to the whole Internet.

5. Wayland, X11, and session semantics

GNOME Remote Desktop works with the current GNOME session and Wayland stack, making it appropriate for GNOME sharing or login. TigerVNC Xvnc/Xtigervnc creates a separate virtual X server; it does not mirror the physical Wayland desktop. x0vncserver targets an existing X display and must not be assumed to capture a native Wayland session.

Decide between “share this desktop” and “create a virtual desktop.” Do not cross the boundary by guessing DISPLAY=:0, copying .Xauthority, attaching to a user's session as root, or disabling Wayland. Desktop environment, GPU/portal, lock screen, audio, clipboard, and application keyring can differ across sessions and require separate testing.

6. When TigerVNC fits

TigerVNC fits an independent persistent virtual X11 desktop, not the current GNOME/Wayland screen. Use the current Ubuntu repository package or an official upstream release. Inspect local man pages, vendor unit, and configuration paths first because the old vncserver wrapper, upstream ~/.config/tigervnc/config, and Ubuntu/Debian ~/.vnc/tigervnc.conf/service integration can differ.

Upstream TigerVNC recommends starting through vncsession or the vendor systemd service and advises against running as root. Do not restore the 2014 vnc4server, a custom root unit, rc.local, cron, or background & startup.

7. The Ubuntu vendor-service owner must be explicit

Read the current unit and documentation first; never overwrite /usr/lib/systemd/system:

systemctl cat 'tigervncserver@.service'
man -P cat tigervncsession | sed -n '1,220p'
man -P cat tigervnc.conf | sed -n '1,220p'
find /usr/share/xsessions -maxdepth 1 -type f -name '*.desktop' -print

Current Ubuntu packaging may map displays to users through /etc/tigervnc/vncserver.users. After administrative review and backup, add one mapping for a dedicated non-root account. Do not preserve the placeholder as a literal username or map several users to one display.

:1=REMOTE_DESKTOP_USER

Replace REMOTE_DESKTOP_USER with an existing, constrained account approved to run a desktop. Display :1 conventionally maps to RFB TCP 5901, but prove it with the real socket rather than trusting the formula alone.

8. TigerVNC localhost configuration example

This is a minimal intent example for Ubuntu/Debian-style ~/.vnc/tigervnc.conf. Validate syntax and the available session against local tigervnc.conf(5x). TLSVnc still authenticates with a VNC password but wraps RFB in TLS; outer SSH/VPN remains the primary access control. Do not add a non-TLS VncAuth fallback or None.

$localhost = "yes";
$SecurityTypes = "TLSVnc";
$NeverShared = "yes";
$session = "gnome";
$geometry = "1920x1080";

localhost=yes is a hard boundary: the listener must be only 127.0.0.1 and/or ::1, never 0.0.0.0, [::], or a public interface. If the installed release uses the newer upstream format, do not paste Perl; follow its matching HOWTO to express equivalent localhost and security-type settings.

9. Credentials must not enter argv

Run interactive vncpasswd as the ordinary user who will own the VNC session. Do not use vncpasswd -f to pipe plaintext from a command line and do not use Xvnc's Password parameter. Confirm the actual password file is owner-only:

umask 077
vncpasswd
stat -c '%a %U %G %n' "$HOME/.vnc/passwd" "$HOME/.config/tigervnc/passwd" 2>/dev/null

TigerVNC's official vncpasswd documentation says the traditional file is only obfuscated and recoverable by someone who reads it, and only the first eight characters are significant. This is not a modern strong secret merely because it is “long.” Use a unique random value never reused elsewhere as inner authentication, with an independent SSH key/VPN/gateway strong identity and loopback binding. If the threat model requires current MFA or identity policy, supply that at the outer access layer.

10. Start once; do not enable yet

Verify the vendor unit and start one test instance without enabling it at boot:

UnitPath="$(systemctl show 'tigervncserver@:1.service' -p FragmentPath --value)"
test -r "$UnitPath" || exit 1
sudo systemd-analyze verify "$UnitPath"
sudo systemctl start 'tigervncserver@:1.service'
sudo systemctl status 'tigervncserver@:1.service' --no-pager
sudo systemctl show 'tigervncserver@:1.service' -p FragmentPath -p MainPID -p ActiveState
ps -eo user,pid,ppid,cmd | grep -E '[X]tigervnc|[v]ncsession'
ss -lntp 'sport = :5901'

Confirm the mapped non-root user owns the process, the socket is loopback-only, and the session type and desktop are correct. On 0.0.0.0:5901, [::]:5901, root ownership, an unknown command line, or duplicate servers, stop immediately. Do not use a firewall as the only patch for a wrong bind.

11. Establish a local SSH tunnel from the client

First verify ordinary SSH login, host key, dedicated key/MFA where available, account allowlist, and the second management path. Then run one foreground tunnel on the client. 15901 is client loopback; the server-side destination remains 127.0.0.1:5901:

ssh -N -T -L 127.0.0.1:15901:127.0.0.1:5901 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o StrictHostKeyChecking=yes REMOTE_USER@REMOTE_HOST

The VNC viewer connects only to 127.0.0.1:15901. REMOTE_USER/REMOTE_HOST are placeholders and contain no password. Do not use sshpass, URL credentials, StrictHostKeyChecking=no, or give the private key to a viewer. End with Ctrl+C in the tunnel terminal and confirm the client 15901 listener disappears.

12. Behind CGNAT: VPN, reverse tunnel, or relay

CGNAT cannot be solved by DNS or VNC port forwarding. Prefer an organization-approved VPN with device identity and ACLs. For an OpenSSH reverse tunnel, make the server create a listener only on relay loopback; never use GatewayPorts to publish it:

ssh -N -T -R 127.0.0.1:15901:127.0.0.1:5901 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o StrictHostKeyChecking=yes RELAY_USER@RELAY_HOST

The administrator then forwards relay loopback into their own client through a separate SSH session:

ssh -N -T -L 127.0.0.1:15901:127.0.0.1:15901 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=yes RELAY_USER@RELAY_HOST

The relay needs a distinct account/key, least-privilege forwarding policy, logs, patches, access review, and failure rollback. Do not blindly alter global sshd_config to make remote forwarding work; have an SSH administrator constrain it per user and verify effective configuration first.

If you already have a relay and up to three of your own computers but are unsure whether the reverse tunnel, listener addresses, and recovery path are tight enough, I offer a fixed USD 250 LazyRemote Network Fit Review. Start with metadata only—no passwords, private keys, or unredacted configuration. Deployment and hardware are not included.

13. Firewall and authenticated TLS gateway

Loopback-only VNC needs no ufw allow 5901, and the router must not forward ports in the 5900 range. Restrict SSH, VPN, or RDP firewall rules to approved management networks/devices, checking IPv4, IPv6, cloud security groups, and upstream routers. Collect read-only ufw/ss evidence first and handle any rule change through separate approval; this guide gives no command to open access to every source.

If browser or cross-organization access is mandatory, use a maintained TLS gateway with valid certificate verification, strong user authentication/MFA, rate limits, session timeout, audit, and a backend allowlist. Backend VNC remains on loopback/private interfaces. HTTPS on a gateway does not justify anonymous VNC, shared accounts, or skipped certificate checks.

14. Verification matrix and evidence

Check	Expected evidence	Action on failure
Process owner	VNC/session belongs to approved non-root user	Stop unit; correct mapping
Bind address	VNC only on `127.0.0.1`/`::1`	Stop; do not open firewall
Tunnel	`ExitOnForwardFailure` succeeds; client only listens on `127.0.0.1:15901`	Close tunnel; inspect conflict/SSH policy
Authentication	Outer SSH/VPN/gateway and inner VNC credentials are independent	Rotate and prohibit sharing
Encryption	GNOME RDP fingerprint matches; VNC crosses networks only over protected transport	Disconnect immediately
Session	Current desktop or independent X session matches intent	Do not patch with a `DISPLAY` hack
Firewall	No public 5900 range; non-approved sources rejected	Roll back rule and investigate
Reboot	Only approved enabled owner returns	Disable unit; inspect duplicate startup

Save package versions, unit FragmentPath, non-sensitive config hashes, process owner, socket address, firewall rule ID, fingerprint-check result, test time, and rollback result. Never save desktop contents, keystrokes, clipboard, credentials, or private keys.

15. Clipboard, files, lock screen, and accessibility

Remote control can read the screen, type keys, and synchronize clipboard. Close password managers, chats, recovery codes, and sensitive documents during testing. Disable clipboard/file transfer when not required. Sharing the current desktop needs a visible on-screen indicator and local disconnect action.

Test lock, logout, user switching, suspend/resume, keyboard layouts, IMEs, scaling, multiple monitors, screen readers, and emergency disconnect separately. A remote-desktop password cannot be assumed to unlock full-disk encryption, a display manager, or an expired user session.

16. Persistence, logs, and updates

Consider systemctl enable for the vendor instance only after one-shot connection, disconnect, and rollback all pass. Do not create a duplicate custom unit or run GNOME RDP, Xvnc, x0vncserver, and another agent simultaneously without documented ownership. Recheck session semantics and binds after every package, desktop, or Wayland update.

Retain only connection time, source identity, result, and necessary error class. Do not leave debug logging enabled or record clipboard/authentication material. Alert on repeated failures, anomalous sources, service crashes, and unexpected public listeners, with a defined retention and access policy.

17. Rollback and stop conditions

Close the viewer/tunnel first, then stop the remote desktop. Roll back a TigerVNC test instance with:

sudo systemctl disable --now 'tigervncserver@:1.service'
sudo systemctl status 'tigervncserver@:1.service' --no-pager
ss -lntp 'sport = :5901'
sudo systemctl reset-failed 'tigervncserver@:1.service'

For GNOME, turn off Desktop Sharing/Remote Login in Settings and then confirm the user unit and socket. Restore old config/firewall through its original approval path. Never recursively delete ~/.vnc, ~/.config, a user home, vendor systemd units, or desktop packages.

Stop and escalate if any of these is true: it can bind only to 0.0.0.0/[::]; the only option is public anonymous or DES-style-only VNC; a password must enter argv; the server can run only as root; a host key/TLS fingerprint cannot be checked; the only SSH/physical recovery is unavailable; session/lock-screen semantics are unknown; connection requires disabling Wayland, firewall, or certificate verification; or the sharing user did not consent.

18. Current official and upstream references

References checked on 2026-09-01. GNOME Remote Desktop, TigerVNC packaging, session names, unit names, and client capabilities change; use the installed UI, man pages, vendor unit, and corresponding official documentation.

19. Historical 2014 source archive (provenance only)

The outer fence below preserves the complete visible source_export body byte for byte; no trailing whitespace was normalized and no private value was redacted. Its vnc4server, vague firewall advice, password-length-only rule, direct vncserver startup, :1 connection, and dead plaintext-HTTP reference are inert historical evidence, not current instructions.

~~~~markdown

尽管我们在大部分情况下用ssh登录Ubuntu服务器就好了，但是有时候我们的程序需要在图形界面下运行，这时我们就要用到vnc server这个软件了。在Ubuntu下安装vnc server很简单的，只要下面几步就可以了：

第一步，获取安装文件

sudo apt-get install vnc4server

第二步，修改VNC Password，不能太短

＃ vncpasswd

Password: ******

Verify:*****

第三步，检查防火墙，这个就不详细说明了

第四步，启动VNC server

vncserver

第五步，通过客户端连接

地址后面加:1

本篇文章来源于 Linux公社网站(www.linuxidc.com) 原文链接：http://www.linuxidc.com/Linux/2007-11/9252.htm
~~~~

Secure Remote Desktop on Ubuntu: GNOME RDP, TigerVNC, SSH Tunnels, and Wayland Boundaries