Serveur Linux de bureau distant : X11VNC & RustDesk

Vous gérez ou dépannez des machines Linux à distance et en avez assez des solutions bricolées — SSH pour l'accès shell, copie manuelle de gros fichiers, ou envoyer à chaque fois un lien TeamViewer. Si vous voulez un bureau distant persistant côté serveur sur Linux qui démarre au boot, survit aux redémarrages et peut être auto‑hébergé sous votre contrôle, ce tutoriel présente deux approches pratiques côté serveur : X11VNC pour les sessions X11 classiques et le démon serveur RustDesk pour une option moderne d'auto‑hébergement en rendez‑vous/relay.

Quand exécuter un serveur de bureau distant linux (et pourquoi)

Checklist rapide pour décider si un bureau distant côté serveur est pertinent :

• Vous avez besoin d'un accès sans tête ou non supervisé à une machine (serveurs de labo, postes de travail de bureau, kiosques).
• Vous voulez un point de terminaison unique, toujours disponible, auquel se connecter sans demander à quelqu'un de lancer un client au préalable.
• Vous préférez l'auto‑hébergement (pas de cloud tiers) ou voulez un relais local pour éviter d'exposer directement des ports RDP/VNC.
• Vous souhaitez combiner l'accès VNC X11 classique avec un traversée NAT/relay moderne pour la commodité du client.

X11VNC est un petit démon VNC mature côté serveur qui expose ce qui est affiché sur l'écran X11 (généralement :0). Les composants serveur de RustDesk (hbbs + hbbr) fournissent le rendez‑vous et un relais optionnel pour les connexions peer‑to‑peer — utile quand les clients sont derrière un NAT. Les deux peuvent coexister : X11VNC vous donne un point VNC toujours actif, et RustDesk vous offre un moyen géré pour que les clients trouvent votre hôte sans redirection de port.

Option A — X11VNC : accès X11 stable, simple et côté serveur

Utilisez X11VNC si vos machines exécutent un environnement X11 et que vous voulez un serveur VNC simple qui démarre au boot. X11VNC est éprouvé (version stable commune : x11vnc 0.9.16 dans de nombreux dépôts) et s'intègre bien avec systemd.

Installer et sécuriser x11vnc

Sur Debian/Ubuntu :

sudo apt update
sudo apt install -y x11vnc

Créez un fichier de mot de passe (utilisez une phrase secrète robuste). Remplacez 'remote' par le propriétaire du répertoire personnel du remote user.

sudo -u remote mkdir -p /home/remote/.vnc
sudo -u remote x11vnc -storepasswd /home/remote/.vnc/passwd
sudo chown -R remote:remote /home/remote/.vnc

Trouvez le bon fichier d'autorité X pour votre gestionnaire d'affichage. Emplacements courants :

• LightDM: /var/run/lightdm/root/:0
• GDM (GNOME): /run/user/1000/gdm/Xauthority or check /home/<username>/.Xauthority

Lancez x11vnc manuellement une fois pour valider :

sudo -u remote x11vnc -display :0 -auth /home/remote/.Xauthority -rfbauth /home/remote/.vnc/passwd -forever -shared -noxdamage -o /var/log/x11vnc.log

Unité systemd pour un service toujours actif

Placez ce fichier dans /etc/systemd/system/x11vnc.service — éditez User, Group et le chemin -auth pour correspondre à votre distro/gestionnaire d'affichage.

[Unit]
Description=x11vnc server for display :0
After=graphical.target

[Service]
Type=simple
User=remote
Group=remote
ExecStart=/usr/bin/x11vnc -display :0 -auth /home/remote/.Xauthority -rfbauth /home/remote/.vnc/passwd -forever -shared -noxdamage -repeat -o /var/log/x11vnc.log
Restart=on-failure

[Install]
WantedBy=graphical.target

Activer et démarrer :

sudo systemctl daemon-reload
sudo systemctl enable --now x11vnc.service
sudo journalctl -u x11vnc -f

Considérations réseau et sécurité

VNC est par défaut non chiffré. Options pour durcir un point VNC côté serveur :

• Attacher à localhost et exiger un tunnel SSH : lancez x11vnc avec -rfbport 5901 et configurez systemd pour n'écouter que sur 127.0.0.1, puis utilisez SSH -L 5901:localhost:5901.
• Utiliser un VPN pour accéder au LAN de l'hôte.
• Limiter l'accès avec un pare‑feu (exemple ufw ci‑dessous).
• Si vous avez besoin d'accès direct sans SSH, placez VNC derrière un stunnel/NGINX TLS proxy (ajoute CPU et complexité).

# Basic UFW rule to allow local-network VNC only
sudo ufw allow from 192.168.0.0/16 to any port 5900 proto tcp
# Or bind to localhost and tunnel via SSH for remote access

Remarques : X11VNC requiert une session X11. Sur Wayland (GNOME sur certaines distributions), utilisez des serveurs compatibles Wayland (par ex. wayvnc) ou le bureau fournit souvent son propre bureau distant (souvent RDP).

Option B — démon serveur RustDesk : rendez‑vous et relay auto‑hébergés

RustDesk vous permet d'auto‑héberger le service de signalisation (hbbs) et le relais (hbbr) afin que les clients puissent trouver et atteindre vos hôtes sans exposer les ports bruts VNC/RDP. Si vous exécutez déjà X11VNC pour la session de bureau, vous pouvez le placer derrière RustDesk pour la traversal NAT et une meilleure expérience client. Les composants serveur de RustDesk sont souvent fournis en images docker ; consultez les releases du projet — exemples de tags serveur incluent v1.2.0 (vérifiez le tag actuel sur le repo RustDesk).

Exemple simple Docker Compose

Ce compose démarre hbbs (rendez‑vous) et hbbr (relais optionnel). Les ports affichés sont des valeurs par défaut courantes utilisées dans la documentation communautaire (ajustez si l'amont change les ports).

version: '3.7'
services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbs
    restart: unless-stopped
    ports:
      - '21112:21112/tcp'   # rendezvous
    environment:
      - HBBS_KEY=your_secret_key_here

  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbr
    restart: unless-stopped
    ports:
      - '21113:21113/udp'   # relay

Remarques :

• Remplacez HBBS_KEY (ou autres vars d'env selon les instructions RustDesk actuelles) par une valeur sécurisée.
• Les images officielles et les noms de variables d'environnement de RustDesk peuvent changer entre les releases — consultez le dépôt serveur RustDesk avant mise en production.

Connexion des clients

Côté client (RustDesk desktop/mobile), pointez le client vers l'adresse de votre serveur hbbs (nom DNS ou IP publique) : par ex. 1.2.3.4:21112. Si le relais hbbr est disponible et nécessaire, le client l'utilisera pour faire transiter le trafic quand la connexion directe (P2P) échoue. Vous pouvez ensuite configurer le client pour prendre le contrôle d'un agent RustDesk exécuté sur l'hôte ou utiliser RustDesk comme courtier qui se connecte à un service VNC existant sur l'hôte (pour cela vous lancez typiquement l'agent RustDesk sur l'hôte, qui peut à son tour forwarder vers la session X11VNC).

Alternative systemd à Docker

Si vous préférez éviter Docker, compilez les binaires rustdesk-server en suivant la documentation du projet et installez‑les comme services systemd (hbbs et hbbr). Le packaging varie selon les releases ; l'approche Docker est la méthode la plus rapide pour obtenir un serveur reproductible.

Sécurité, traversée NAT et quand éviter d'exposer des ports

Deux approches générales pour éviter d'exposer directement les ports du bureau :

1. Garder VNC/RDP lié à localhost ; exiger SSH/VPN pour atteindre l'hôte. C'est l'option la plus simple et la plus auditable pour les installations gérées par un seul administrateur.
2. Auto‑héberger un relay/rendezvous (RustDesk) et utiliser TLS + authentification. Cela réduit les ports ouverts sur l'hôte mais nécessite d'exploiter et de sécuriser les serveurs de relais.

Extraits de règles de pare‑feu (UFW) :

# Allow only SSH from your office and block the rest
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
sudo ufw deny 5900/tcp

# If running RustDesk server on the relay box (example)
sudo ufw allow 21112/tcp
sudo ufw allow 21113/udp

Checklist pratique de sécurité :

• Utilisez une authentification forte pour le compte agent VNC ou RustDesk.
• Faites tourner ou protégez les clés serveur (RustDesk HBBS key) et gardez les images à jour.
• Utilisez IDS/monitoring pour alerter sur les scans de ports et tentatives de connexion échouées.
• Si vous exigez des sessions de bureau chiffrées, terminez le TLS à un reverse proxy (Nginx/Caddy) devant le relais et imposez TLS 1.2+ et des suites de chiffrement robustes.

Astuces opérationnelles, dépannage et maintenance

Problèmes courants et corrections :

• Pas de bureau visible via VNC : confirmez que l'affichage X est :0 (ps aux | grep X) et que x11vnc utilise le bon fichier -auth.
• Le service ne démarre pas au boot : définissez WantedBy sur graphical.target et vérifiez que le gestionnaire d'affichage démarre avant x11vnc.
• Les clients RustDesk ne joignent pas le serveur : vérifiez DNS et pare‑feu ; testez avec des outils telnet/IP et inspectez les logs des conteneurs (docker-compose logs -f).
• Mauvaise performance : activez -noxdamage pour x11vnc (moins d'artefacts, moins de CPU pour certains workloads) et envisagez d'ajuster compression/encodages côté client si disponible.

Playbook de maintenance :

• Appliquez les mises à jour de sécurité de l'OS chaque semaine. Sur Debian/Ubuntu, vous pouvez automatiser avec unattended-upgrades pour les correctifs mineurs.
• Suivez les dépôts upstream de RustDesk ou x11vnc pour les correctifs de sécurité. Si vous utilisez des images docker, planifiez un rafraîchissement des images et un pipeline de redéploiement.
• Sauvegardez les fichiers de configuration et les certificats TLS ; stockez les clés HBBS dans un gestionnaire de secrets si possible.

Quand un outil commercial ou RDP peut être préférable

Compromis honnêtes :

• TeamViewer / AnyDesk : ils l'emportent en simplicité extrême pour des utilisateurs non techniques, traversal NAT universel et applications mobiles soignées. Si vous avez besoin d'un support instantané et sans configuration pour des centaines de postes non techniques, un SaaS commercial peut valoir le coût. Voir notre comparaison sur rustdesk-vs-anydesk pour les détails.
• RDP (Microsoft Remote Desktop) : sur serveurs et postes Windows, RDP natif offre généralement de meilleures performances et fonctionnalités (presse‑papier, transfert de fichiers, son). Mais RDP expose une surface d'attaque plus importante si non placé derrière un VPN ou un bastion.

Si votre objectif principal est l'auto‑hébergement et la confidentialité — et que vous acceptez un peu plus de configuration initiale et de maintenance continue — la combinaison X11VNC + RustDesk server est une approche pratique et robuste.

Lectures complémentaires et ressources internes

Si vous voulez éviter la redirection de ports entièrement, lisez notre guide : Bureau à distance sans redirection de ports. Pour une vue plus générale du déploiement de votre propre solution, voyez Guide du bureau à distance auto‑hébergé. Pour les meilleures pratiques de durcissement, consultez Sécurité du bureau à distance.

Enfin, Tenvo se concentre sur des outils de bureau à distance ouverts et auto‑hégés — si vous cherchez un client/serveur alternatif conçu pour l'auto‑hébergement et multi‑plateforme, consultez nos pages de téléchargement ou de tarification pour commencer : /download et /pricing. Nous décrivons des schémas de déploiement similaires dans d'autres articles et tenons les exemples à jour.

Si vous voulez de l'aide pour une distro spécifique, un gestionnaire d'affichage ou pour ajuster un démarrage systemd pour un environnement particulier, indiquez la distro et le gestionnaire d'affichage (par ex. Ubuntu 22.04 avec GDM) et je vous fournirai une unité systemd et les commandes auth adaptées. Quand vous serez prêt, téléchargez Tenvo ou essayez de construire la stack décrite ci‑dessus — commencez par /download.