Quand plusieurs machines tournent en local, le vrai sujet n’est pas seulement d’y accéder, mais de le faire sans déplacer écran, clavier et souris à chaque fois. X11vnc répond précisément à ce besoin : partager la session graphique réelle d’un poste Ubuntu ou Debian, puis s’y connecter depuis Windows avec un client VNC. On va faire propre. Pas besoin de JavaScript pour ça, seulement une configuration claire, quelques commandes utiles et un peu d’attention sur la sécurité VNC.
L’article en bref
X11vnc permet de reprendre la main sur une machine Linux en gardant le bureau déjà ouvert. L’objectif est simple : une connexion distante fluide en réseau local, avec une installation sobre et un partage d’écran facile à maintenir.
- Installation rapide sur Debian et Ubuntu : Un paquet, un mot de passe, puis le service démarre
- Partage de la session réelle : L’écran physique reste accessible depuis un autre poste
- Démarrage automatique fiable : systemd relance le serveur VNC au boot
- Connexion depuis Windows : Un client VNC suffit pour piloter la machine
Un guide utile pour installer, sécuriser et exploiter X11vnc sans alourdir la machine.
X11vnc sur Ubuntu, Debian et Windows : le bon outil pour afficher un bureau à distance
Le besoin est très concret : accéder à une machine qui tourne déjà, voir ce qui se passe sur son écran, lancer une mise à jour, corriger un script ou relancer une application bloquée. Ici, SSH ne remplace pas le bureau graphique, il répond à un autre usage. X11vnc s’adresse justement aux cas où l’interface visuelle compte autant que la ligne de commande.
Dans un réseau local, cette approche reste simple, efficace et cohérente. Une station Linux peut rester allumée en permanence, puis devenir accessible à la demande depuis Windows. Le navigateur adore ça ? Non. Le système, lui, préfère surtout moins de complexité et une chaîne de rendu légère.
Pourquoi choisir X11vnc plutôt qu’une session virtuelle
La vraie question n’est pas comment. C’est pourquoi. X11vnc partage la session graphique déjà ouverte, au lieu de créer un bureau séparé. Résultat : ce qui s’affiche localement est exactement ce qui est visible à distance.
Ce choix est particulièrement utile sur une machine de labo, un mini-PC ou un poste de test. Il évite de gérer plusieurs sessions, et garde l’environnement de travail intact. Pour un administrateur qui veut voir une fenêtre, pas seulement des logs, c’est la voie la plus directe.
Le piège ici : confondre confort et légèreté. VNC n’est pas fait pour la 3D lourde ni pour du streaming vidéo. Son terrain naturel, c’est le dépannage, le contrôle ponctuel et l’administration graphique.
Quand utiliser VNC et quand préférer SSH
SSH reste le meilleur choix pour administrer un serveur sans interface, transférer des fichiers ou exécuter des tâches distantes en terminal. Pour cela, il est imbattable. Mais dès qu’il faut cliquer, vérifier une boîte de dialogue ou manipuler un logiciel graphique, VNC prend l’avantage.
Sur un réseau local, cette complémentarité fonctionne très bien. Une machine peut être administrée en SSH au quotidien, puis pilotée en VNC pour les opérations visuelles. Moins de propriétés = plus de fluidité, surtout quand l’objectif est de rester simple.
Installation de X11vnc sur Ubuntu et Debian : version minimale et version optimisée
On va faire propre. La base tient en quelques commandes : installation du paquet, création d’un mot de passe VNC, puis activation du service. Cette approche fonctionne bien sur Ubuntu comme sur Debian, avec un comportement stable sur un poste en local.
Le point décisif, ce n’est pas seulement d’installer le serveur VNC. C’est aussi de préparer la suite : démarrage automatique, port réseau clair et accès protégé. Si votre animation lag, regardez ici : en administration système aussi, la simplicité réduit les frictions.
Commande d’installation et mot de passe
Version minimale : installer X11vnc puis définir un mot de passe dédié. Cette étape permet d’éviter un accès ouvert sur le port VNC et de garder une base saine dès le départ.
Voici le noyau utile :
sudo apt install x11vnc
x11vnc -storepasswd
Le mot de passe est ensuite enregistré dans le répertoire VNC de l’utilisateur. Cette séparation est pratique : elle rend la configuration réutilisable et plus lisible, sans multiplier les réglages inutiles.
Création du service systemd pour un démarrage automatique
Version optimisée : transformer le lancement manuel en service systemd. C’est la bonne méthode quand la machine doit rester disponible après chaque redémarrage.
Le fichier de service peut contenir une commande de ce type :
| Élément | Rôle | Impact pratique |
|---|---|---|
| ExecStart | Lance x11vnc avec ses options | Le serveur démarre sans intervention |
| -rfbport 5901 | Définit le port VNC | Connexion claire depuis le client |
| -rfbauth | Charge le mot de passe | Protège l’accès distant |
| -forever | Maintient le service actif | Réduit les coupures de session |
| -noxdamage | Améliore la compatibilité graphique | Évite certains artefacts d’affichage |
Le piège ici : oublier de remplacer le nom d’utilisateur dans le chemin du fichier de mot de passe. C’est le genre de détail invisible qui bloque tout le service. Une fois le fichier en place, systemd prend le relais proprement.
Les commandes à retenir sont simples :
sudo systemctl daemon-reload
sudo systemctl enable x11vnc.service
sudo systemctl start x11vnc.service
sudo systemctl status x11vnc.service
Si l’état affiche active (running), la base est solide. C’est le moment où l’installation cesse d’être théorique et devient réellement exploitable au quotidien.
Configuration réseau, sécurité VNC et port d’écoute sur Debian dérivé d’Ubuntu
Un serveur VNC ne sert à rien si le réseau le bloque. Il faut donc autoriser le port choisi et vérifier que la machine reste joignable sur l’adresse correcte. En local, fixer l’IP simplifie énormément la vie, surtout quand le DHCP change d’avis après un redémarrage.
La sécurité VNC mérite aussi une attention minimale. Même en réseau local, mieux vaut éviter une configuration ouverte par habitude. Un accès protégé et un port explicite valent mieux qu’un service lancé à l’aveugle.
Ouvrir le port et stabiliser l’accès
Pour autoriser les connexions, le port 5901 peut être ouvert via UFW. Sur une distribution dérivée de Debian, cette étape rend le service accessible depuis le poste client.
sudo ufw allow 5901/tcp
sudo ufw enable
Quand le pare-feu est déjà actif, seule la règle d’ouverture est nécessaire. Le point clé est simple : le serveur VNC doit écouter sur un port connu, sinon le client ne trouvera rien.
Pourquoi l’adresse IP fixe change tout
Un réseau local peut paraître stable, puis devenir pénible dès qu’une machine change d’adresse. Une IP fixe évite cette chasse permanente. C’est particulièrement utile quand plusieurs postes Ubuntu ou Debian doivent rester accessibles en permanence.
Un petit laboratoire de test, un PC de salon ou un poste de production légère gagnent tous en lisibilité avec ce choix. Une fois l’adresse maîtrisée, la connexion distante devient presque immédiate. Le gain de temps est modeste à chaque fois, mais immense sur plusieurs semaines.
Se connecter depuis Windows avec un client VNC
Depuis Windows, le principe reste identique : un client VNC, l’adresse IP de la machine Linux et le bon port. TightVNC, RealVNC ou UltraVNC remplissent tous cette mission. Le choix relève surtout de l’habitude et du confort d’usage.
Le plus important est ailleurs : la cible doit être joignable, le mot de passe correct, et la session graphique déjà prête côté serveur. Quand ces trois points sont bons, l’écran distant s’affiche sans détour. C’est brut, simple, et justement efficace.
Étapes de connexion côté client
Dans le client VNC, il suffit d’indiquer l’adresse IP suivie du port, par exemple 192.168.1.200:5901. Une invite de mot de passe apparaît ensuite, puis le bureau distant se charge.
Une liste de contrôle rapide aide à éviter les retours en arrière :
- Vérifier l’IP : la machine Linux doit être sur la bonne adresse
- Confirmer le port : le client doit viser 5901 si c’est celui choisi
- Saisir le mot de passe : la protection VNC doit correspondre au serveur
- Tester le service : systemd doit indiquer un état actif
Ce type de connexion convient très bien à un poste Windows qui doit piloter une machine Linux sans débrancher le matériel. Une fois lancé, le bureau apparaît comme s’il était physiquement sous les yeux.
Réglages utiles si l’affichage semble instable
Certains clients affichent mieux la session que d’autres. Si l’image saccade ou semble mal rafraîchie, il faut d’abord regarder la qualité d’image côté client, puis les options serveur comme -noxdamage.
Le piège ici : vouloir corriger un problème graphique en ajoutant de la complexité. En pratique, quelques paramètres bien choisis suffisent souvent. Le navigateur adore ça ? Toujours pas. Le GPU, lui, apprécie les chemins de rendu courts.
| Symptôme | Cause probable | Réglage conseillé |
|---|---|---|
| Connexion refusée | Port fermé ou IP erronée | Revoir UFW et l’adresse cible |
| Image lente | Options serveur trop lourdes | Réduire les effets et activer -noxdamage |
| Demande de mot de passe répétée | Fichier d’authentification incorrect | Vérifier le chemin rfbauth |
| Déconnexion soudaine | Service stoppé ou instable | Contrôler systemd et les logs |
X11vnc sur X.Org et Wayland : ce qui change vraiment
Sur X.Org, X11vnc reste dans son terrain le plus naturel. Il s’attache à l’écran existant et partage le display actif, ce qui simplifie beaucoup la configuration. Sur Wayland, le contexte est différent : le partage d’écran passe souvent par un composant dédié comme gnome-remote-desktop.
Cette distinction compte, car elle évite de chercher la même recette partout. Un poste GNOME récent n’expose pas l’écran de la même manière qu’une session X11 classique. Là encore, le bon outil dépend du serveur d’affichage en place.
Identifier le serveur d’affichage avant d’agir
Avant toute installation, il faut savoir si la session utilise X11 ou Wayland. Cette vérification évite de configurer le mauvais service et de perdre du temps pour rien.
Dans un environnement GNOME, une commande comme loginctl show-session … -p Type permet de voir le type de session. On peut aussi vérifier la variable d’environnement liée à la session. C’est une étape discrète, mais décisive.
Pourquoi Wayland demande une autre approche
Wayland impose une couche supplémentaire pour le partage d’écran. Le bureau doit être exposé via un mécanisme compatible, souvent intégré à GNOME. Ce n’est pas une faiblesse, juste une architecture différente.
Pour un usage local, cela reste tout à fait exploitable. Mais la méthode n’est pas identique à celle d’X11, et c’est précisément ce qui évite les fausses bonnes solutions. Une configuration propre commence par une bonne identification du contexte.
Bonnes pratiques pour une connexion distante stable et réactive
Le vrai confort ne vient pas d’une longue liste d’options, mais d’un ensemble de réglages sobres. Sur une machine en réseau local, X11vnc peut rester très fluide si le port est stable, le mot de passe bien configuré et la session graphique peu sollicitée.
Un projet passé de 38 fps à 60 fps uniquement en retirant deux propriétés inutiles rappelle une règle simple : chaque détail compte. Ici aussi, moins de complexité signifie souvent plus de réactivité. Une animation magnifique mais inutilisable sur mobile n’aide personne ; un bureau distant lent non plus.
Les réglages qui améliorent vraiment l’usage
Pour garder une session agréable, il vaut mieux éviter les effets superflus, surveiller les déconnexions et relancer proprement le service si besoin. L’option -forever aide à maintenir la connexion active, tandis que systemd apporte une reprise fiable.
Le retour d’expérience le plus utile tient souvent en une phrase : si ça saccade, c’est que c’est mal pensé. Ce n’est pas une question de puissance brute, mais de chemin d’exécution et de sobriété des réglages.
Quand le bureau distant sert à dépanner, administrer ou vérifier une interface, il doit rester discret et rapide. C’est exactement là que X11vnc trouve sa place.
Cas d’usage concret en réseau local
Imaginons une petite station Ubuntu dans un coin du bureau, une Debian sur une table de test et un poste Windows au centre. Avec X11vnc, chacun reste accessible sans permuter les périphériques à chaque tâche.
Le gain est immédiat : lancer une mise à jour, vérifier une fenêtre figée, corriger une configuration ou consulter une interface graphique devient trivial. Et surtout, la session affichée reste la vraie session de la machine.
X11vnc fonctionne-t-il sur Ubuntu et Debian ?
Oui. X11vnc s’installe facilement sur Ubuntu et Debian via le gestionnaire de paquets, puis il partage la session graphique existante.
Peut-on se connecter depuis Windows ?
Oui. Un client VNC sous Windows suffit, à condition d’indiquer l’adresse IP de la machine Linux et le port configuré, comme 5901.
X11vnc est-il adapté à Internet ?
Non, pas directement. Pour une vraie exposition hors réseau local, il faut renforcer la sécurité VNC, idéalement via tunnel chiffré ou VPN.
Pourquoi le serveur ne démarre pas après redémarrage ?
Le service systemd peut ne pas être activé, ou le chemin du fichier de mot de passe peut contenir un nom d’utilisateur incorrect.
Quelle différence entre X11vnc et un bureau virtuel VNC ?
X11vnc partage l’écran réel de la machine, alors qu’un serveur VNC classique peut créer une session séparée. C’est idéal quand il faut voir exactement la session locale.
