Serveur de bureau à distance Linux : configuration X11VNC et daemon RustDesk

Vous cherchez à permettre à des personnes (ou vous-même) de se connecter à un bureau Linux de façon fiable, sécurisée et sans passer par des services propriétaires coûteux — et les manuels que vous avez trouvés sont soit trop vagues, soit rédigés pour des utilisateurs d’interface graphique. Ce guide montre deux approches serveur pratiques pour un serveur de bureau à distance Linux : une configuration X11VNC éprouvée pour exposer directement une session X, et un daemon RustDesk auto‑hébergé (hbbs/hbbr) pour une traversée NAT moderne et un relais — avec commandes réelles, unités systemd, exemples Docker et étapes concrètes de durcissement.

Pourquoi exécuter un serveur de bureau à distance Linux ? Arbre de décision rapide

Avant de plonger dans les commandes : choisissez le modèle qui correspond à vos besoins.

• Si vous avez besoin d’un accès direct à la session X physique d’une machine (prise en charge de l’utilisateur connecté, état de session local, plusieurs écrans), X11VNC est l’outil serveur le plus simple.
• Si vous voulez un modèle client/serveur qui prend en charge la traversée NAT, des serveurs d’ID, des relais et des clients multiplateforme plus simples — et que vous souhaitez auto‑héberger ces composants serveur — exécutez les daemons hbbs/hbbr de RustDesk.
• Si vous voulez simplement un tunnel rapide sur une machine pour une assistance ponctuelle, un tunnel SSH ou l’utilisation d’un service hébergé peut rester plus rapide. Voir aussi notre guide sur le self-hosted remote desktop pour la stratégie et les compromis.

Note : des produits commerciaux comme TeamViewer et AnyDesk l’emportent souvent sur la commodité pure (traversée NAT automatique et codecs optimisés prêts à l’emploi). Ce sont des choix raisonnables si vous avez besoin d’une fiabilité plug‑and‑play et d’un support commercial ; voir notre comparaison des fonctionnalités dans rustdesk-vs-anydesk.

1) X11VNC : un serveur de bureau à distance Linux minimal exposant la session X physique

X11VNC se connecte à un serveur X existant et sert le bureau courant. Ce n’est pas un bureau virtuel séparé — il reflète l’interface graphique affichée localement. Cela le rend excellent pour l’assistance à distance et l’administration lorsque vous voulez interagir avec la même session qu’un utilisateur local.

Prérequis et versions recommandées

• Fonctionne sur les environnements de bureau basés sur X11. Pour Wayland, utilisez les API distantes spécifiques au compositeur ou une autre approche.
• Installez x11vnc >= 0.9.16 (0.9.16+ apporte des fonctionnalités modernes et des améliorations de stabilité).
• Assurez‑vous d’avoir un gestionnaire d’affichage (gdm/lightdm/sddm) ou une session X en cours sur :0.

Installation sur Debian/Ubuntu (exemple) :

sudo apt update
sudo apt install -y x11vnc xauth

Créez un fichier de mot de passe (gardez‑le sécurisé) :

sudo x11vnc -storepasswd /etc/x11vnc.pass
sudo chown root:root /etc/x11vnc.pass
sudo chmod 600 /etc/x11vnc.pass

Unit systemd simple pour démarrer automatiquement sur l’affichage :0 (placer en /etc/systemd/system/x11vnc.service) :

[Unit]
Description=x11vnc - VNC server for :0
After=display-manager.service

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pass -rfbport 5900 -shared -ncache 10
User=root
Restart=on-failure

[Install]
WantedBy=graphical.target

Activer et démarrer :

sudo systemctl daemon-reload
sudo systemctl enable --now x11vnc.service
sudo systemctl status x11vnc.service

Notes de sécurité pour X11VNC

• N’exposez pas TCP/5900 directement sur Internet sans protections supplémentaires. L’authentification VNC est acceptable en LAN mais doit être considérée comme faible sur des réseaux publics.
• Préférez un tunnel SSH pour l’accès distant : ssh -L 5900:localhost:5900 user@your-server puis connectez un client VNC à localhost:5900.
• Si vous avez besoin de TLS direct, utilisez stunnel ou un VPN. Ou placez VNC derrière un pare‑feu adapté et exigez l’accès via VPN.

Conseils de performance

• Utilisez -ncache 10 pour réduire les pics de bande passante lorsque le contenu du bureau change rapidement.
• Lorsque vous observez une charge CPU élevée sur des liaisons 1–2 Mbps, réduisez la profondeur de couleur ou utilisez des options de compression (x11vnc prend en charge -compresslevel et -quality). Expérimentez — une qualité inférieure donne souvent une meilleure réactivité perçue.

2) RustDesk daemon : relais auto‑hébergé et serveur d’ID pour un accès distant moderne

RustDesk fournit un client qui peut utiliser un serveur d’ID central (hbbs) et un relais (hbbr) pour connecter des pairs même derrière NAT. Héberger vos propres hbbs/hbbr vous donne le contrôle total des IDs et des relais — important si vous voulez éviter des serveurs tiers. C’est la configuration côté serveur que la plupart des gens entendent quand ils demandent un serveur de bureau à distance Linux en modèle auto‑hébergé.

Pourquoi exécuter hbbs/hbbr au lieu d’un unique binaire ? Hbbs est le serveur d’ID (authentification, attribution), hbbr est le serveur relais (relais TCP/UDP pour le média lorsque le P2P direct échoue). Les deux sont légers et souvent exécutés dans Docker.

Versions recommandées : utilisez les composants serveur RustDesk 1.1.9+ (ou le tag stable le plus récent au moment du déploiement). Consultez les notes de version du projet RustDesk avant les déploiements en production.

Exemple Docker Compose pour hbbs + hbbr (minimal)

version: '3.3'
services:
  hbbs:
    image: rustdesk/rustdesk-server:1.1.9
    container_name: rustdesk_hbbs
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"  # hbbs TCP (ID server)
    environment:
      - RUST_LOG=info
    volumes:
      - ./data/hbbs:/data

  hbbr:
    image: rustdesk/rustdesk-server:1.1.9
    container_name: rustdesk_hbbr
    restart: unless-stopped
    ports:
      - "21116:21116/tcp"  # hbbr TCP (relay)
      - "21116:21116/udp"  # hbbr UDP for hole punching/relay
    environment:
      - RUST_LOG=info
    volumes:
      - ./data/hbbr:/data

Remarques sur les ports et le NAT

• Les ports par défaut de RustDesk couramment mappés sont 21115 (hbbs serveur d’ID) et 21116 (hbbr relais). UDP est utile pour la traversée NAT ; ouvrez TCP et UDP si possible.
• Placez le serveur sur une IP publique ou sur un hôte avec IP/DNS statique. Utilisez un enregistrement A/AAAA pour le nom d’hôte que vous configurez dans les clients.

Configuration côté client

Pointez le client RustDesk vers le nom d’hôte de votre hbbs et activez le relais si nécessaire. Vous pouvez forcer l’utilisation du relais pour la confidentialité ou autoriser le pair‑à‑pair si les deux clients peuvent effectuer le NAT punching. L’interface de configuration du client accepte le nom d’hôte et le port de votre serveur (par ex., server.example.com:21115).

Sécurisation d’un déploiement auto‑hébergé du daemon RustDesk

Le trafic par défaut de RustDesk est chiffré entre pairs, mais les composants serveur authentifient et coordonnent. Envisagez ces mesures de durcissement :

• Exécutez hbbs/hbbr derrière un pare‑feu et n’ouvrez que les ports nécessaires (21115 TCP, 21116 TCP/UDP). Utilisez UFW ou firewall-cmd ; exemple : sudo ufw allow 21115/tcp; sudo ufw allow 21116/tcp; sudo ufw allow 21116/udp.
• Utilisez TLS/HTTPS pour toute interface d’administration exposée au web. Si vous terminez TLS sur un reverse proxy (nginx/caddy), gardez le backend isolé.
• Surveillez les journaux et l’utilisation des ressources. Les composants RustDesk sont légers mais surveillez le nombre de connexions et la bande passante des relais.
• Envisagez la limitation de débit et fail2ban sur l’hôte si vous constatez des tentatives de force brute contre le port hbbs.

Quand choisir RustDesk vs X11VNC

• Choisissez RustDesk lorsque vous avez besoin d’un support client multiplateforme (Windows/Mac/Linux/Android/iOS), de traversée NAT et d’un ID/relais auto‑hébergé pour de nombreux terminaux. C’est une solution moderne pour des flottes distribuées.
• Choisissez X11VNC lorsque vous intervenez sur des machines de bureau spécifiques et devez interagir avec la session X locale (par exemple, dépannage de l’utilisateur connecté ou problèmes graphiques au démarrage).

Notes pratiques de production et réglages de performance

Bande passante et CPU : attendez‑vous à ce que les sessions de bureau à distance directes consomment entre 1–5 Mbps pour des tâches bureautiques typiques avec codecs compressés ; le partage d’écran pour des vidéos ou des jeux fera grimper les pics. Si vous hébergez votre propre relais (hbbr), prévoyez la bande passante du relais : 100 sessions simultanées à 2 Mbps = ~200 Mbps de capacité continue.

Surveillance et autoscaling : pour de plus grandes organisations, exécutez hbbs derrière un petit HA proxy ou un load balancer, et déployez plusieurs relais hbbr répartis par région. Utilisez une orchestration de conteneurs standard (Docker Swarm ou Kubernetes) si vous avez besoin d’auto‑scaling ; sinon, une VM relais puissante suffit pour de petites équipes.

Journalisation et dépannage

• Les journaux x11vnc apparaissent dans le journal systemd : sudo journalctl -u x11vnc.service
• Conteneurs RustDesk : docker logs rustdesk_hbbs et docker logs rustdesk_hbbr pour les erreurs de démarrage. Vérifiez l’accessibilité des ports avec ss ou netstat et testez UDP/TCP depuis un client distant.
• Si les connexions directes échouent, confirmez que l’UDP n’est pas bloqué par des NAT intermédiaires ou des pare‑feu ; de nombreux opérateurs bloquent des plages UDP peu courantes.

Comparaison de sécurité et avis franc sur les éditeurs

Si la sécurité et la confidentialité sont vos priorités, l’auto‑hébergement de hbbs/hbbr vous donne le contrôle des métadonnées et des points de relais. Cependant, des éditeurs propriétaires comme TeamViewer ou AnyDesk peuvent fournir une traversée NAT plus robuste prête à l’emploi, des codecs propriétaires réduisant le débit sur des liaisons faibles, et un support/SLAs de niveau entreprise. Ils sont pertinents si vous avez besoin d’un support commercial 24/7 garanti et d’une mise en service simplifiée pour des utilisateurs non techniques — mais cette commodité a un coût. Voir anydesk-pricing-explained pour les différences de tarification et les compromis.

Liste de contrôle pratique avant la mise en production

1. Décidez du modèle adapté (X11VNC pour les sessions physiques vs RustDesk pour l’accès à distance basé sur ID/relais).
2. Durcissez le serveur : pare‑feu, clés SSH uniquement, limitation avec fail2ban, et TLS lorsque applicable.
3. Testez depuis l’extérieur de votre réseau : vérifiez le comportement des relais, la latence et la tolérance aux pannes.
4. Mettez en place la surveillance (journaux, bande passante, redémarrages de processus) et une politique d’alerte en cas d’incident.

Lectures complémentaires et ressources internes

Si vous évaluez des options auto‑hébergées plus larges et leurs compromis, lisez notre guide self-hosted remote desktop à /self-hosted-remote-desktop. Pour une comparaison ciblée des fonctionnalités entre RustDesk et des options commerciales, voyez /rustdesk-vs-anydesk.

Notes pratiques finales

Les deux approches sont maintenables, mais elles résolvent des problèmes légèrement différents. X11VNC est simple et prévisible pour des postes uniques ; les daemon(s) RustDesk montent mieux en charge pour des flottes et gèrent la traversée NAT correctement lorsqu’ils sont configurés. Dans tous les cas, n’exposez jamais un VNC non chiffré directement sur Internet — utilisez toujours des tunnels SSH, des VPN ou un relais correctement durci.

Prêt à l’essayer ? Téléchargez les clients Tenvo (godeskflow) ou consultez notre documentation serveur à /download — et si vous avez besoin d’options tarifaires ou entreprise, regardez /pricing. Déployez une instance de test, exercez vos règles de pare‑feu et validez le comportement client avant un déploiement utilisateur.