Bureau Linux sans écran : sessions de bureau réelles

Votre serveur est joignable mais quand vous vous connectez vous obtenez un écran noir, un petit framebuffer virtuel ou pas d'accélération GPU — parce que la machine n'a pas d'écran connecté. Ce guide montre comment obtenir une session de bureau réelle et utilisable sur un Linux headless : options matérielles et logicielles, commandes pas à pas, unités systemd, particularités Wayland et comment se connecter en sécurité (y compris l'option relay géré de Tenvo).

Ce que « bureau réel » signifie sur une machine headless

Par « bureau réel » j'entends une session de bureau qui se comporte comme si un écran était connecté : résolution plein écran, sortie GPU correcte (si applicable), persistance de la session après redémarrage, mappage clavier/souris prévisible et la possibilité d'exécuter des environnements Wayland ou X11 plutôt qu'un petit framebuffer 800×600 Xvfb. Une machine headless peut présenter soit un affichage virtuel (émulation logicielle) soit un affichage physique (clé HDMI dummy ou KMS virtuel). Le choix dépend de si vous avez besoin d'accélération GPU, de fonctionnalités DRM/KMS, ou simplement d'un bureau interactif pour l'administration.

Trois approches pratiques — choisir selon le besoin

• Dummy HDMI matériel — le plus simple pour l'accélération GPU. Branchez un dummy HDMI « headless ghost » à $2 pour simuler un écran ; le GPU et le gestionnaire d'affichage produisent une session normale et une résolution adéquate.
• X virtuel / Xvfb ou pilote dummy Xorg + gestionnaire d'affichage — uniquement logiciel et très compatible : crée une session X11 complète que vous pouvez exposer via VNC (TigerVNC) ou partager avec x11vnc. Xvfb est le plus simple mais n'expose pas KMS/accélération GPU.
• RDP via xrdp (recommandé dans de nombreux cas) — xrdp lance une vraie session X (ou utilise XorgXrdp) et fournit un point d'accès RDP. Fonctionne bien sur les serveurs headless car il ne nécessite pas d'écran physique et est largement supporté par les clients Windows/macOS.

Option A — clé HDMI dummy (astuce matérielle)

Si vous avez besoin d'accélération GPU (OpenGL, décodage matériel, sortie de compositeur Wayland) c'est l'astuce la plus rapide et la plus fiable : achetez un petit dummy HDMI (émulateur EDID) qui annonce un écran en 1920×1080 ou 2560×1440. Branchez-le sur la sortie HDMI du GPU, redémarrez si nécessaire, et votre gestionnaire d'affichage (GDM, SDDM, LightDM) créera une session normale. Pas de bidouille logicielle, pas de framebuffers virtuels.

Avantages : vrai GPU, pas de configuration. Inconvénients : accès physique requis, impossible si le système n'a pas de connecteur d'affichage ou est dans une baie scellée.

Option B — session X virtuelle : Xvfb + bureau + TigerVNC (exemple Ubuntu/Debian)

Utilisez ceci quand vous ne pouvez pas brancher un dummy ou quand l'accélération GPU n'est pas requise. Cela produit une session de bureau complète indépendante d'un écran physique et fonctionnera sur toute distribution avec X11.

sudo apt update
sudo apt install -y xvfb tigervnc-standalone-server xfce4 xfce4-goodies

# Créez un utilisateur VNC dédié (optionnel)
sudo adduser vncuser

# Exemple : démarrer un affichage Xvfb persistant et XFCE
sudo -u vncuser Xvfb :99 -screen 0 1920x1080x24 &
export DISPLAY=:99
sudo -u vncuser startxfce4 &

# Démarrer TigerVNC pour exposer :99 sur le TCP 5901
sudo -u vncuser x0vncserver -display :99 -passwordfile /home/vncuser/.vnc/passwd -forever -shared

# Ou lancer tigervncserver directement si vous voulez des sessions X gérées par VNC
sudo -u vncuser tigervncserver :1 -geometry 1920x1080 -depth 24

Unité systemd : rendre l'affichage persistant au démarrage. Enregistrez sous /etc/systemd/system/xvfb-vnc.service (adapter les chemins et l'utilisateur) :

[Unit]
Description=Xvfb + desktop + VNC
After=network.target

[Service]
Type=simple
User=vncuser
Environment=DISPLAY=:99
ExecStart=/usr/bin/Xvfb :99 -screen 0 1920x1080x24
ExecStartPost=/usr/bin/sleep 1
ExecStartPost=/usr/bin/startxfce4
Restart=on-failure

[Install]
WantedBy=multi-user.target

Remarques : Xvfb fournit uniquement un framebuffer logiciel ; l'accélération GPU matérielle n'est pas disponible. Pour beaucoup de tâches d'administration et d'applications GUI c'est suffisant. Si vous avez besoin d'une session avec GPU, utilisez le dummy HDMI ou le pilote dummy Xorg combiné au pilote GPU (ci‑dessous).

Option C — pilote dummy Xorg / serveur X headless (pour sessions gérées par le DM)

Au lieu de Xvfb vous pouvez configurer Xorg pour utiliser le pilote vidéo « dummy » afin que le gestionnaire d'affichage du système (GDM/LightDM) crée une session de connexion normale au démarrage. C'est plus proche d'une session sur moniteur réel et parfois plus compatible que Xvfb.

# Installer le pilote dummy Xorg et un environnement léger (Debian/Ubuntu)
sudo apt install -y xserver-xorg-video-dummy xfce4

# Exemple minimal /etc/X11/xorg.conf.d/10-dummy.conf
Section "Device"
  Identifier "DummyDevice"
  Driver "dummy"
EndSection

Section "Monitor"
  Identifier "DummyMonitor"
  HorizSync 28.0-80.0
  VertRefresh 48.0-75.0
EndSection

Section "Screen"
  Identifier "DummyScreen"
  Device "DummyDevice"
  Monitor "DummyMonitor"
  SubSection "Display"
    Depth 24
    Modes "1920x1080"
  EndSubSection
EndSection

Après avoir créé cette configuration, activez votre gestionnaire d'affichage et redémarrez. Le DM devrait afficher un greeter normal et produire des sessions que vous pouvez accéder avec x11vnc (pour partager le bureau existant) ou via un serveur VNC attaché à l'affichage X.

Option D — xrdp : sessions RDP adaptées au headless

xrdp est une bonne option parce qu'il crée une session X à la demande et parle RDP, largement supporté par les clients. Il ne dépend pas d'un écran connecté et est souvent l'approche la moins capricieuse pour l'accès GUI à distance sur des serveurs.

sudo apt install -y xrdp xfce4 xfce4-terminal
# Configurer XFCE pour xrdp : créer ou éditer /home/you/.xsession ou /etc/xrdp/startwm.sh
echo "startxfce4" > /home/you/.xsession
sudo systemctl enable --now xrdp
# Ouvrez le pare-feu pour TCP/UDP 3389 seulement si vous contrôlez le réseau ; préférez un tunnel SSH ou le relais Tenvo

Puis connectez-vous avec n'importe quel client RDP sur le port 3389 ou via un tunnel SSH. xrdp peut utiliser XorgXrdp pour de meilleures performances ; vérifiez les paquets de votre distribution pour la version xorgxrdp correspondante.

Wayland : mises en garde et options

Les compositeurs Wayland gèrent les sorties différemment et ont historiquement un support limité ou inexistant pour les affichages virtuels. GNOME sur Wayland n'acceptera pas un affichage Xvfb ; il attend une sortie DRM/KMS. Vos options :

• Utiliser un dummy HDMI pour que le compositeur croit qu'un écran est présent.
• Lancer une session Xorg à la place (installer une session X11 comme XFCE ou GNOME sur Xorg) et utiliser Xvfb/xrdp/VNC.
• Pour les compositeurs basés sur wlroots, étudier wlr-rdp ou wayvnc (la maturité des projets varie selon le compositeur).
• Pour des flottes importantes nécessitant Wayland, envisager une GPU tête‑sans‑écran matérielle ou un pilote enterprise GPU headless — mais cela requiert souvent des paquets fournisseur et des hooks noyau.

Si vous dépendez de Wayland, lisez notre article approfondi sur Wayland Remote Desktop: PipeWire, portals and gaps avant de choisir une solution.

Connectivité réseau : relais Tenvo et notes de sécurité

Une fois la session de bureau disponible, il faut une connexion fiable. Tenvo propose des clients natifs sur macOS/Windows/Linux, un client navigateur en bêta publique, et un relais géré multi‑régions qui est le comportement recommandé par défaut pour la plupart des utilisateurs. Offres : Free $0, Lite $2.99/mo, Pro $7.99/mo. Le relais géré évite d'avoir à configurer des règles de pare‑feu, le NAT traversal et à maintenir une flotte TURN/STUN.

Soyez explicite sur le chiffrement : Tenvo utilise TLS avec des certificats par appareil. Une connexion directe peer‑to‑peer est chiffrée de bout en bout entre les deux appareils. Quand le trafic passe par un relais, TLS se termine au relais, ce qui signifie que l'opérateur du relais peut accéder au trafic de session. Si une exigence de conformité interdit l'infrastructure tierce, l'auto‑hébergement est la bonne option — sinon le coût opérationnel d'auto‑héberger (mises à jour, garde des clés, bascule) est souvent supérieur à un relais géré. Voir Self-Hosted Remote Desktop: Why, How, and What Breaks pour savoir quand choisir l'auto‑hébergement.

Si vous voulez éviter complètement le port‑forwarding tout en utilisant votre propre relais ou tunnel, consultez Remote Desktop Without Port Forwarding Explained.

Checklist de dépannage (écrans noirs, mauvaise résolution, problèmes clavier)

• Écran noir après connexion : vérifiez les logs du gestionnaire d'affichage (journalctl -u gdm -b ou journalctl -u lightdm) et /var/log/Xorg.0.log pour des erreurs.
• Framebuffer trop petit (ex. 640×480) : définissez un mode personnalisé dans la configuration dummy X ou utilisez xrandr pour ajouter un mode (fonctionne seulement si X expose la sortie).
• Mappage clavier/souris incorrect : vérifiez la locale et les réglages xkb, et contrôlez que le client VNC/RDP n'impose pas de disposition ; testez avec une console virtuelle locale (chvt) si possible.
• Pas de GPU/OpenGL : Xvfb n'offre pas d'accélération GPU. Utilisez un dummy HDMI ou un pilote vendor headless si vous avez besoin d'accélération matérielle.
• Greeter Wayland mais pas de session : passez à une session X ou branchez un dummy display ; vérifiez les logs du compositeur (journalctl pour gnome-shell ou le service du compositeur).

Pour les corrections courantes d'écran noir, consultez notre guide de dépannage : Remote desktop black screen troubleshooting flow. Inspectez aussi Xauthority, la propriété de /tmp/.X11-unix, et assurez‑vous que l'utilisateur a un shell valide et un répertoire home.

Quand auto‑héberger vs utiliser le relais géré Tenvo

Choisissez l'auto‑hébergement uniquement si vous avez une politique écrite interdisant les relais tiers (résidence des données, certains régimes de conformité), ou si la machine est sur un réseau isolé. Sinon, le relais géré Tenvo est la valeur pratique par défaut : il réduit la charge d'astreinte, gère les certificats TLS et offre une bascule multi‑régions. Si vous prévoyez d'auto‑héberger, lisez les compromis dans Self-Hosted Remote Desktop: Why, How, and What Breaks et préparez‑vous à exécuter un cluster de relais, gérer la rotation des certificats, la journalisation et la supervision.

Référence rapide : commandes et vérifications

# Vérifier l'affichage actif
echo "$DISPLAY"
# Tester la connectivité X
xdpyinfo -display :0 || xdpyinfo -display :99
# Voir les logs du DM
sudo journalctl -u gdm -b --no-pager
# Log Xorg
sudo tail -n 200 /var/log/Xorg.0.log
# Voir les écrans/sorties
DISPLAY=:0 xrandr --listmonitors || DISPLAY=:99 xrandr --listmonitors
# Activer xrdp
sudo systemctl enable --now xrdp

Si vous migrez depuis un outil de bureau à distance qui « fonctionnait toujours » lorsqu'un écran était connecté, souvenez‑vous : les machines headless changent les hypothèses que l'OS et les pilotes font sur les écrans. Commencez par la solution la plus simple (dummy HDMI) et passez aux solutions logicielles si l'accès matériel est impossible.

Prêt à essayer ? Téléchargez Tenvo, testez une connexion non supervisée via le relais géré, et choisissez l'approche de bureau ci‑dessous qui correspond à votre GPU et à vos contraintes de conformité : Download Tenvo.