Bureau distant sur un VPS Linux avec xrdp
Installez XFCE avec xrdp sur votre VPS Linux, faites passer RDP dans un tunnel SSH sans ouvrir le port 3389 et découvrez quand préférer RustDesk.
Ce que signifie réellement un bureau distant sur un VPS Linux
Deux types de produits correspondent à la recherche « remote desktop on a Linux VPS ». Choisir le mauvais vous fera perdre un après-midi. Le premier est un broker d’accès distant. Le serveur RustDesk auto-hébergé en est l’exemple courant : il relaie une session entre deux machines que vous possédez déjà, par exemple votre ordinateur portable et le PC de votre domicile. Le serveur loué n’affiche aucun bureau. Il met les deux extrémités en relation et transfère les paquets lorsqu’elles ne peuvent pas communiquer directement. Le second est un véritable bureau graphique exécuté sur le serveur loué. Les pixels sont donc générés dans le data centre, puis transmis jusqu’à vous. Il peut s’agir de xrdp, de VNC (virtual network computing) ou d’un espace de travail dans un conteneur.
Une question permet de les distinguer. Une fois la configuration terminée, où se trouve le pointeur de la souris ? S’il se trouve sur une machine que vous possédez déjà, vous avez besoin d’un broker. S’il se trouve sur le VPS lui-même, vous avez besoin d’un bureau sur le VPS. La suite porte principalement sur le second cas, car c’est celui que la plupart des guides omettent.
Quelle option correspond à votre usage
- RustDesk avec votre propre relay. La session ne transite pas par un serveur public de rendez-vous géré par des tiers, car vous détenez la paire de clés. Cela ne protège pas la machine contrôlée : il s’agit toujours du PC sur lequel vous avez installé le client, avec le mot de passe défini sur ce PC.
- xrdp via un tunnel SSH ou un VPN. Vous êtes protégé contre le scan permanent d’Internet sur TCP 3389 et contre les tentatives de deviner le mot de passe de l’écran de connexion RDP, car ce port n’est jamais exposé sur Internet. Cela ne protège pas un mot de passe de compte faible contre une personne qui dispose déjà du tunnel.
- VNC via le même tunnel. Vous disposez d’une session de bureau qui survit aux déconnexions, avec un protocole plus ancien et plus simple que RDP. VNC ne protège rien à lui seul : toute la sécurité repose sur le tunnel. VNC seul sur un port public est donc la pire option ici.
- Un workspace conteneurisé tel que Webtop ou Kasm. Vous disposez d’un navigateur ou d’un bureau complet dans un conteneur que vous pouvez supprimer et reconstruire, ce qui protège votre véritable machine contre ce que ce navigateur peut toucher. Cela ne protège pas l’hôte : ces images s’exécutent avec des privilèges étendus et un
sudosans mot de passe à l’intérieur. Le conteneur ne constitue donc pas une frontière de sécurité à laquelle vous devriez confier une charge de travail hostile.
Installer xrdp et XFCE sur Ubuntu 24.04
Une image de serveur VPS ne contient aucun environnement de bureau graphique. Vous en installez un, puis vous installez xrdp, le serveur open source qui utilise RDP (remote desktop protocol), le même protocole que le client Windows. Choisissez un environnement de bureau léger. XFCE est généralement le choix adapté.
sudo apt update
sudo apt install -y xrdp xorgxrdp xfce4 xfce4-goodies dbus-x11
systemctl is-active xrdpUbuntu 24.04 fournit xrdp 0.9.24 et xorgxrdp dans le composant universe, en août 2026. Installez xorgxrdp explicitement, même s’il s’agit seulement d’un paquet recommandé : c’est le backend du serveur X que xrdp démarre pour une nouvelle session. Sans lui, la boîte de connexion accepte votre mot de passe, puis vous renvoie directement à la boîte de connexion.
Indiquez ensuite à la session quel environnement de bureau démarrer. xrdp exécute /etc/xrdp/startwm.sh, qui exécute ~/.xsession lorsque ce fichier existe.
echo "xfce4-session" > ~/.xsession
chmod 644 ~/.xsessionEnfin, xrdp doit pouvoir lire la clé TLS (transport layer security) qu’il propose aux clients. Ce fichier utilise le mode 640 et appartient au groupe ssl-cert.
ls -l /etc/ssl/private/ssl-cert-snakeoil.key
id xrdpLa liste affiche -rw-r----- 1 root ssl-cert. Si id xrdp n’affiche pas ssl-cert parmi les groupes, exécutez sudo adduser xrdp ssl-cert, puis sudo systemctl restart xrdp. Si vous omettez cette étape, xrdp ne peut pas ouvrir la clé et /var/log/xrdp.log enregistre l’échec avec le nom de fichier snakeoil dans la ligne.
Pourquoi ne pas ouvrir le port 3389 sur Internet
Le port TCP 3389 est analysé en permanence par tout ce qui se trouve sur Internet, et une boîte de dialogue de connexion RDP répond docilement à chaque tentative de mot de passe. Ne l’ouvrez pas. Liez plutôt xrdp à l’adresse loopback et utilisez un tunnel auquel vous faites déjà confiance.
Modifiez /etc/xrdp/xrdp.ini et changez l’écouteur dans la section [Globals].
[Globals]
port=tcp://.:3389Le fichier fourni documente cette syntaxe dans ses propres commentaires : tcp://.:3389 signifie 127.0.0.1:3389, et tcp://:3389 signifie toutes les interfaces. Redémarrez le service et vérifiez, car une faute de frappe peut laisser silencieusement le service à l’écoute sur toutes les adresses.
sudo systemctl restart xrdp
ss -tlnp | grep 3389Vous devez obtenir 127.0.0.1:3389. Si vous voyez 0.0.0.0:3389, xrdp a ignoré votre modification. La cause la plus fréquente est que la ligne se trouve finalement sous un autre en-tête de section, plus bas dans le fichier.
Ouvrez maintenant le tunnel depuis votre propre machine.
ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com-N signifie « ouvrir la connexion sans exécuter de commande ». La session sert donc uniquement à transporter le port. Laissez ce terminal ouvert et configurez le client RDP pour utiliser 127.0.0.1:3389. Sur un client Linux, le logiciel est FreeRDP 3. Sous Ubuntu 24.04, son binaire s’appelle xfreerdp3 :
sudo apt install -y freerdp3-x11
xfreerdp3 /v:127.0.0.1:3389 /u:you /dynamic-resolution +clipboard /soundSous Windows, utilisez mstsc, puis saisissez 127.0.0.1 comme nom de l’ordinateur. FreeRDP vous demande d’accepter le certificat lors de la première connexion et affiche Do you trust the above certificate? (Y/T/N). C’est normal avec le certificat snakeoil auto-signé.
Si ssh répond bind [127.0.0.1]:3389: Address already in use, un autre processus sur votre propre machine utilise déjà le port 3389. Déplacez l’extrémité locale avec ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com et connectez-vous à 127.0.0.1:13389.
Un tunnel par personne devient vite contraignant. Pour une équipe, un réseau privé constitue une meilleure solution. Placez la machine derrière un VPN WireGuard auto-hébergé, attribuez-lui l’adresse du tunnel 10.8.0.1 et définissez port=tcp://10.8.0.1:3389 afin que xrdp ne réponde qu’à l’intérieur du VPN. Dans tous les cas, la règle du pare-feu pour le port 3389 ne doit pas exister. Si vous ne savez pas exactement ce qu’autorisent vos règles actuelles, commencez par les bases du pare-feu ufw sur un VPS et vérifiez-les avant de vous connecter, pas après.
Quelle quantité de RAM utilise un bureau distant sur un VPS de 2 GB
Le bureau que vous choisissez détermine si une offre de 2 GB est confortable ou inutilisable. Les chiffres ci-dessous sont des valeurs typiques arrondies de la mémoire utilisée juste après la connexion sur Ubuntu 24.04. Ils proviennent de comparaisons publiées et non de mesures effectuées sur votre machine. Mesurez votre propre consommation avec free -m juste après vous être connecté.
The data behind this chart
[
{
"label": "LXQt",
"idle_ram_mb": 300
},
{
"label": "XFCE",
"idle_ram_mb": 400
},
{
"label": "MATE",
"idle_ram_mb": 500
},
{
"label": "KDE Plasma",
"idle_ram_mb": 800
},
{
"label": "GNOME",
"idle_ram_mb": "1,200"
}
]Sur ces 5 bureaux, l’écart est le point important. LXQt utilise environ 300 MB et XFCE environ 400 MB. Ils laissent donc tous deux assez de mémoire sur une machine de 2 GB pour un navigateur. GNOME demande environ 1,200 MB avant même l’ouverture d’une fenêtre. Avec 2 GB, le navigateur doit alors se partager la mémoire restante avec le bureau.
Le navigateur représente le principal coût, pas le shell du bureau. Un navigateur moderne utilise entre 150 et 400 MB par onglet actif. Un VPS de 2 GB sous XFCE peut donc gérer quelques onglets avant de commencer à utiliser le swap. Ajoutez du swap afin que la machine ralentisse au lieu d’arrêter des processus : sudo fallocate -l 2G /swapfile, puis sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile, et ajoutez une ligne correspondante dans /etc/fstab pour que le swap soit conservé après un redémarrage. Lorsqu’un processus disparaît sans avertissement, exécutez dmesg | grep -i "killed process". Cette ligne indique que l’out-of-memory killer du kernel l’a arrêté. Le navigateur est généralement le processus concerné.
Le CPU est l’autre limite, et elle est plus facile à sous-estimer. Un VPS n’a pas de GPU. X utilise donc le rendu logiciel via llvmpipe, ce qui signifie que le CPU calcule chaque pixel. Faire défiler une page lourde et lire une vidéo se traduisent par une charge CPU élevée. La fréquence d’affichage diminue au lieu que la machine se fige. C’est la même limite que celle rencontrée si vous vous demandez si vous pouvez jouer sur un VPS : pour tout ce qui est en 3D, la réponse est non, précisément pour cette raison.
Son et presse-papiers dans une session xrdp
Ubuntu 24.04 utilise PipeWire, tandis que la redirection audio de xrdp a été conçue pour PulseAudio. Une installation fraîche fournit donc la vidéo, mais pas le son. Ubuntu fournit le bridge nécessaire.
sudo apt install -y pipewire-module-xrdp pulseaudio-utils alsa-utilsDéconnectez-vous complètement de la session RDP, puis reconnectez-vous, car le module est chargé au démarrage de la session. Une simple reconnexion ne suffit pas. Vérifiez ensuite depuis la session :
pactl list short sinks
speaker-test -c 2 -t wav -l 1Vous devez voir un sink dont le nom contient xrdp et entendre la tonalité de test sur votre client. Si aucun sink xrdp n’apparaît, le module n’a pas été chargé dans cette session. Votre client doit également demander la redirection audio : il s’agit du flag /sound de xfreerdp3, ou du paramètre « Audio distant » dans les ressources locales du client Windows.
Le presse-papiers texte fonctionne dans les deux sens une fois que xrdp-chansrv est exécuté pour votre session, ce que xrdp fait automatiquement. Vérifiez-le avec pgrep -a xrdp-chansrv. Si le copier-coller cesse de fonctionner en cours de session, ce processus s’est arrêté ; une reconnexion le redémarre. La copie de fichiers, contrairement à celle du texte, utilise un canal distinct appelé redirection de lecteurs : /drive:home,/home/you sur xfreerdp3 monte un dossier local dans la session distante.
La fenêtre polkit et les autres échecs de la première connexion
La surprise la plus fréquente lors de la première connexion est une boîte de dialogue contenant Authentication is required to create a color managed device. La cause est précise. Le service colord demande une autorisation à polkit. polkit n’accorde cette action sans confirmation qu’à une session qu’il considère comme locale. Une session RDP n’est pas considérée comme locale. polkit demande donc votre mot de passe. Ubuntu 24.04 fournit polkit 124, qui a supprimé les anciens fichiers d’autorité locale .pkla. Tous les guides qui vous demandent d’écrire /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla sont donc sans effet sur 24.04. Écrivez plutôt une règle JavaScript.
/* /etc/polkit-1/rules.d/45-allow-colord.rules */
polkit.addRule(function(action, subject) {
if (action.id.indexOf("org.freedesktop.color-manager.") === 0 &&
subject.isInGroup("sudo")) {
return polkit.Result.YES;
}
});Exécutez sudo systemctl restart polkit, puis reconnectez-vous. Deux autres échecs sont utiles à reconnaître à leurs symptômes.
La boîte de connexion accepte votre mot de passe, puis réapparaît immédiatement. La session a démarré, puis s’est arrêtée. Consultez d’abord /var/log/xrdp-sesman.log, puis ~/.xsession-errors dans votre répertoire personnel. Un fichier xorgxrdp manquant, un fichier ~/.xsession qui désigne un bureau non installé, un répertoire personnel dans lequel vous ne pouvez pas écrire ou un disque plein aboutissent tous à ce résultat.
Vous vous connectez et voyez un écran gris avec un curseur en forme de X. X a démarré, mais pas le bureau. Il s’agit encore de ~/.xsession : exécutez xfce4-session manuellement via SSH et lisez l’erreur affichée.
Fonctionnement du serveur RustDesk auto-hébergé
RustDesk se compose de deux processus. hbbs est le serveur d’identification et de rendez-vous auquel les clients s’enregistrent, tandis que hbbr est le relais qui transporte la session lorsqu’une connexion pair à pair directe échoue. Aucun des deux n’exécute de bureau. Ils proviennent d’une seule image. Voici le fichier Compose publié par le projet, avec l’adresse du relais remplacée par le nom d’hôte de votre serveur :
services:
hbbs:
container_name: hbbs
image: rustdesk/rustdesk-server:latest
command: hbbs -r rustdesk.example.com:21117
ports:
- 21115:21115
- 21116:21116
- 21116:21116/udp
- 21118:21118
volumes:
- ./data:/root
restart: unless-stopped
hbbr:
container_name: hbbr
image: rustdesk/rustdesk-server:latest
command: hbbr
ports:
- 21117:21117
- 21119:21119
volumes:
- ./data:/root
restart: unless-stoppedDémarrez les conteneurs, puis affichez la clé publique générée par le serveur lors de son premier démarrage :
sudo docker compose up -d
sudo cat ./data/id_ed25519.pubChaque client a besoin du nom d’hôte de votre serveur et de cette clé publique. Saisissez ces deux valeurs dans les paramètres Network du client RustDesk. La clé privée correspondante reste dans ./data/id_ed25519. Si vous supprimez le répertoire de données, le serveur génère une nouvelle paire de clés. Tous les clients doivent alors être reconfigurés avec la nouvelle clé. Sauvegardez ce répertoire. Si votre équipe utilise finalement ce serveur pour accéder à toutes les machines, plutôt que pour un simple test occasionnel, consultez la compilation dédiée du relais RustDesk pour la gestion des clés Ed25519, l’utilisation de tags d’image figés à la place de latest et la bande passante du relais facturée par votre offre.
Le pare-feu doit autoriser directement ces ports. hbbs utilise TCP 21115, 21116 et 21118, ainsi que UDP 21116. hbbr utilise TCP 21117 et 21119.
sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp
sudo ufw allow 21118/tcp
sudo ufw allow 21119/tcpPourquoi RustDesk ne fonctionne pas derrière nginx ou Traefik
Les utilisateurs qui terminent déjà TLS pour tous leurs services sur un reverse proxy essaient souvent cette configuration, sans succès. hbbs et hbbr utilisent leurs propres protocoles binaires sur TCP et UDP, et non HTTP. Aucun en-tête Host ne permet d’effectuer le routage et aucune requête HTTP ne peut être inspectée. Un bloc nginx server ou un routeur HTTP Traefik n’a donc aucun élément correspondant. Le listener UDP sur 21116 n’est lié à HTTP à aucun niveau.
Deux solutions fonctionnent. nginx peut transférer les ports TCP avec un bloc stream. Il s’agit d’un transfert de couche 4, et non d’un reverse proxy au sens habituel. Les ports 21118 et 21119 transportent les websockets utilisés par le client web RustDesk. Ils utilisent donc HTTP standard et peuvent être placés derrière votre proxy. Dans ce cas, ajoutez des règles de firewall afin que seul le proxy puisse accéder à 21118 et 21119, car hbbs s’appuie sur l’en-tête X-Real-IP des connexions websocket pour déterminer l’adresse réelle du client.
Un navigateur jetable dans un conteneur
Parfois, vous avez simplement besoin d’un navigateur propre, avec une IP qui ne change pas, isolé de votre propre machine. Un espace de travail dans un conteneur fournit cela avec beaucoup moins de logiciels installés. Webtop de LinuxServer est l’option légère :
services:
webtop:
image: lscr.io/linuxserver/webtop:latest
container_name: webtop
environment:
- PUID=1000
- PGID=1000
- TZ=Etc/UTC
volumes:
- /path/to/data:/config
ports:
- 127.0.0.1:3000:3000
- 127.0.0.1:3001:3001
shm_size: "1gb"
restart: unless-stoppedLe port 3000 sert HTTP et le port 3001 sert HTTPS. Vous accédez au bureau dans un onglet de navigateur, sans aucun client RDP. Les tags d’image couvrent XFCE, KDE, MATE et i3 sur plusieurs distributions de base. La documentation du projet est claire sur le risque : le conteneur dispose d’un accès privilégié à l’hôte et inclut un terminal avec sudo sans mot de passe. Il ne doit donc pas être exposé à Internet sans protection. C’est pourquoi les ports ci-dessus sont liés à 127.0.0.1 au lieu d’être publiés sur toutes les adresses. Accédez-y via le même tunnel SSH ou le même VPN que celui utilisé pour xrdp.
Kasm Workspaces reprend le même principe, mais à une échelle bien supérieure, avec une console web, des comptes utilisateur et des conteneurs par session qui sont réinitialisés à la fin de la session. Il nécessite davantage de ressources qu’un petit VPS. En août 2026, la configuration minimale indiquée dans la documentation est de 2 cœurs CPU, 4 GB de mémoire et 50 GB de SSD. Chaque session utilisateur utilise par défaut 2 cœurs et 2768 MB supplémentaires. Une offre de 2 GB ne suffira pas. L’installation consiste à télécharger un fichier, puis à exécuter un script :
cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.17.0.7f020d.tar.gz
tar -xf kasm_release_1.17.0.7f020d.tar.gz
sudo bash kasm_release/install.shVNC et les cas où il reste pertinent
VNC envoie des mises à jour du framebuffer plutôt que des commandes de dessin. Il paraît donc plus lourd que RDP sur une liaison lente et ne fournit aucun canal audio. Il reste pertinent dans un cas : vous voulez qu’une session de bureau continue de fonctionner après votre déconnexion et retrouver cette même session à votre retour. TigerVNC répond à ce besoin. vncserver -localhost yes :1 lie Xvnc à 127.0.0.1 sur le port TCP 5901 et refuse les connexions provenant d’ailleurs. Vous le tunnelisez donc exactement comme xrdp avec ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com. Ne publiez jamais un port VNC. La plupart des serveurs VNC protègent le mot de passe pendant le handshake, mais rien par la suite. Sur un port public, le contenu de la session est donc lisible sur le réseau.
Un VPS est-il adapté à un poste de travail ?
Pour un usage quotidien, non, et les raisons sont nombreuses. Il n’y a pas de GPU, donc le CPU doit tout afficher. Chaque frappe attend un aller-retour réseau, et une latence de 40 ms, acceptable dans SSH, devient perceptible dans un éditeur de texte. La vidéo est compressée deux fois : une fois par le site, puis par l’encodeur RDP. Vos fichiers sont stockés sur un disque que vous ne contrôlez pas, et un usage intensif du bureau consomme une partie de la bande passante mensuelle prévue pour un serveur web.
Comme machine temporaire, un VPS est très pratique, pour les mêmes raisons. Son adresse IP est stable et appartient à un datacenter, ce qui est utile lorsqu’un service doit voir une adresse constante. La machine peut être reconstruite à partir d’une image en quelques minutes. Une session qui a récupéré un logiciel malveillant ne vous coûte donc rien. Le VPS est isolé de votre matériel réel et continue de fonctionner lorsque votre ordinateur portable est fermé. La facturation à l’heure rend un poste de travail temporaire peu coûteux.
Si vous déterminez encore l’usage de cette machine, la liste pratique des usages adaptés à un VPS mérite d’être consultée avant d’y installer un bureau. Si vous vouliez un bureau pour exécuter une seule application Windows, comparez d’abord ce besoin aux différences réelles entre Linux et Windows Server, car la licence modifie le coût de la solution.
FAQ
Puis-je exécuter un bureau distant sur un VPS de 2 GB ?
Oui, avec un environnement de bureau léger. XFCE ou LXQt utilise environ 300 à 400 MB après la connexion, ce qui laisse assez de mémoire pour un navigateur avec quelques onglets. GNOME ou KDE Plasma sur 2 GB ne laisse presque rien pour les applications. Ajoutez un fichier swap de 2 GB afin que la pression mémoire ralentisse la machine au lieu de tuer des processus. Si un processus disparaît sans message, consultez dmesg | grep -i "killed process" pour vérifier l’action du tueur de processus du noyau en cas de mémoire insuffisante.
Dois-je ouvrir le port 3389 dans le firewall de mon VPS ?
Non. Le port TCP 3389 est constamment analysé et une interface de connexion RDP exposée favorise les tentatives de deviner les mots de passe. Définissez port=tcp://.:3389 dans /etc/xrdp/xrdp.ini afin qu’xrdp écoute uniquement sur 127.0.0.1, vérifiez-le avec ss -tlnp | grep 3389, puis accédez-y avec ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com. Pour plus d’une ou deux personnes, liez xrdp à une adresse WireGuard plutôt qu’à loopback.
Pourquoi xrdp affiche-t-il « Authentication is required to create a color managed device » ?
Le service colord demande une autorisation à polkit, et polkit n’accorde cette action silencieusement qu’à une session locale active. Une session RDP n’est pas considérée comme locale, vous obtenez donc une demande de mot de passe à chaque connexion. Sur Ubuntu 24.04, l’ancien correctif .pkla ne fait rien, car polkit 124 a supprimé les fichiers d’autorité locaux. Créez /etc/polkit-1/rules.d/45-allow-colord.rules avec une règle JavaScript qui renvoie polkit.Result.YES pour les identifiants d’action commençant par org.freedesktop.color-manager., puis exécutez sudo systemctl restart polkit.
Puis-je placer un serveur RustDesk auto-hébergé derrière nginx ou Traefik ?
Pas le service principal. hbbs et hbbr utilisent leurs propres protocoles binaires plutôt que HTTP. Il n’existe donc aucun en-tête Host sur lequel effectuer le routage, et UDP 21116 ne peut pas traverser un proxy HTTP. Ouvrez TCP 21115 à 21119 ainsi que UDP 21116 dans le firewall, puis laissez les clients se connecter directement. Les ports websocket 21118 et 21119, utilisés par le client web, sont en HTTP et peuvent être placés derrière un proxy. Dans ce cas, limitez-les dans le firewall afin que seul le proxy puisse les atteindre, car hbbs fait confiance à X-Real-IP sur ces connexions.
Pourquoi n’y a-t-il pas de son dans ma session xrdp ?
Ubuntu 24.04 utilise PipeWire, alors que la redirection audio d’xrdp a été conçue pour PulseAudio. Le son est donc absent jusqu’à l’installation du bridge. Exécutez sudo apt install -y pipewire-module-xrdp, puis déconnectez-vous complètement de la session et reconnectez-vous, car le module est chargé au démarrage de la session et une reconnexion ne suffit pas à le charger. Vérifiez avec pactl list short sinks la présence d’un sink dont le nom contient xrdp. Vérifiez également que le client demande l’audio : il s’agit du flag /sound avec xfreerdp3, ou de l’option « Remote audio » dans le client Windows.