L'avantage de X2GO est qu'il est "4x4" point de vue possibilité d'usage.
Je me permet de rebondir sur ton post ici pour revenir au besoin de manière générique d'abord, puis et ensuite en apportant une autre réponse à tkr<, ce post n'est donc nullement "une réponse" au tiens, mais juste un complément général.
Accompagnement de l'utilisateur
Administration d'un système
Ce sont deux choses vraiment très différentes en terme de départ. La réalité d'usage fait que le premier mène parfois a des éléments du second, et que le second mène parfois à une documentation :-) En entreprise on dissocie souvent les deux, en espérant pouvoir confier à un "niveau 1" moins cher le premier et le second le faire de manière massive. Menant à une effroyable maintenance pour les outils de maintenance ... Dans le monde plus pragmatique, c'est pourquoi je réagis sous ton post, on ne dissocie pas les deux. A mon humble avis il n'y a pas assez de pragmatisme en entreprise.
Pour revenir à X2GO, il permet de :
ouvrir une nouvelle session graphique distante avec un confort d'usage sans concurrent actuellement (== utilisation de la ressource distante)
prendre la main à distance sur une session graphique locale, toujours avec le même confort d'usage (== accompagnement de l'utilisateur)
congeler une session graphique et la récupérer en l'état plus tard
avec des homes centraux, il devient possible de changer de ressources (aka : changer de machines sur laquelle se connecter) pour le point précédent, donc récupérer sur une autre machine une session congelée sur une première, ça aussi c'est génial.
Jme permet ce rappel car les trois derniers sont peu connus, x2go est souvent résumé uniquement par le premier point.
Enfin, coupler avec VirtualGL il permet d'accéder aux ressources de la carte graphique distante et de faire bosser cette dernière. Et là, c'est le grand roxor (en conf avec un canal de com graphique non chiffré, juste l'auth l'est)
X2GO a d'autres défauts, en 2026 :
Le client Windows n'est pas correctement maintenu, les sessions mortes s'empilent et son usage est devenu laborieux depuis des patchs windows11 de début d'année.
Les paquets RH EPEL sont notoirement buggés, et la gestion des dépendances est devenue hasardeuse.
Enfin, X11/xorg : donc l'avenir de moyen terme est sa mort (bien ou mal, peu importe ici)
J'avais choisi X2GO pour "mon monde", mon service en entreprise, lors du covid, après un bench des soluces existantes. En moins de 2 semaines les usagers des moyens informatiques de mon service avaient un accès distant confortable, on étaient prêts pour le premier confinement. Et la SSI était satisfaite car il s'agissait d'une vraie authentification système via ssh (et avec un serveur bastion, proxy), ils n'ont pas eu à se soucier de nous, contrairement à d'autres services qui collaient du rdp ou pire du vnc. Du coup, petit à petit X2GO s'est imposé et répandu dans l'entreprise, remplaçant au fil du temps et des essais par les autres services les solutions que eux avaient mis en place. On a même fini par s'en servir comme un moyen proxy pour se connecter aux webui d'admin : "vm x2go" obligatoire.
Mais voilà, en 2026 cela ne va plus.
tkr< dit dans un autre post
ce modèle de séparation de l'infra et du logiciel, m'est aujourd'hui indispensable
Pour ça à mon humble avis un Headscale pourrait faire l'affaire. Headscale est le serveur de "contrôle et répartition" de référence : une ré-écriture de celui de TailScale, permettant l'autohébergement, ce que TailScale ne permet pas.
Netbird est bien chouppi mais mon instinct me dit que le risque que ça tourne au fauxpen-source, à l'opencore, est trop grand pour être pris. Nebula pourrait convenir, pas de risque d'opencore, bien maintenu. Mais vraiment orienté infra.
[^] # Re: SSH avec des tunnels
Posté par bubar🦥 . En réponse au journal NoMachine évolue, et pas en mieux.. Évalué à 5 (+2/-0). Dernière modification le 05 septembre 2026 à 05:02.
L'avantage de X2GO est qu'il est "4x4" point de vue possibilité d'usage.
Je me permet de rebondir sur ton post ici pour revenir au besoin de manière générique d'abord, puis et ensuite en apportant une autre réponse à tkr<, ce post n'est donc nullement "une réponse" au tiens, mais juste un complément général.
Ce sont deux choses vraiment très différentes en terme de départ. La réalité d'usage fait que le premier mène parfois a des éléments du second, et que le second mène parfois à une documentation :-) En entreprise on dissocie souvent les deux, en espérant pouvoir confier à un "niveau 1" moins cher le premier et le second le faire de manière massive. Menant à une effroyable maintenance pour les outils de maintenance ... Dans le monde plus pragmatique, c'est pourquoi je réagis sous ton post, on ne dissocie pas les deux. A mon humble avis il n'y a pas assez de pragmatisme en entreprise.
Pour revenir à X2GO, il permet de :
Jme permet ce rappel car les trois derniers sont peu connus, x2go est souvent résumé uniquement par le premier point.
Enfin, coupler avec VirtualGL il permet d'accéder aux ressources de la carte graphique distante et de faire bosser cette dernière. Et là, c'est le grand roxor (en conf avec un canal de com graphique non chiffré, juste l'auth l'est)
X2GO a d'autres défauts, en 2026 :
J'avais choisi X2GO pour "mon monde", mon service en entreprise, lors du covid, après un bench des soluces existantes. En moins de 2 semaines les usagers des moyens informatiques de mon service avaient un accès distant confortable, on étaient prêts pour le premier confinement. Et la SSI était satisfaite car il s'agissait d'une vraie authentification système via ssh (et avec un serveur bastion, proxy), ils n'ont pas eu à se soucier de nous, contrairement à d'autres services qui collaient du rdp ou pire du vnc. Du coup, petit à petit X2GO s'est imposé et répandu dans l'entreprise, remplaçant au fil du temps et des essais par les autres services les solutions que eux avaient mis en place. On a même fini par s'en servir comme un moyen proxy pour se connecter aux webui d'admin : "vm x2go" obligatoire.
Mais voilà, en 2026 cela ne va plus.
tkr< dit dans un autre post
Pour ça à mon humble avis un Headscale pourrait faire l'affaire. Headscale est le serveur de "contrôle et répartition" de référence : une ré-écriture de celui de TailScale, permettant l'autohébergement, ce que TailScale ne permet pas.
Netbird est bien chouppi mais mon instinct me dit que le risque que ça tourne au fauxpen-source, à l'opencore, est trop grand pour être pris. Nebula pourrait convenir, pas de risque d'opencore, bien maintenu. Mais vraiment orienté infra.
?