Bureau à distance

Prendre la main sur un poste graphique du parc pour dépanner son utilisateur, sans rien installer de permanent et sans mot de passe à saisir.

just rd clemence            # observation seule (défaut)
just rd clemence rw         # prise en main
just rd clemence login      # votre propre session, via GDM

ro et rw se rattachent à la session déjà ouverte sur l’hôte : si personne n’est connecté, la commande s’arrête en erreur. login fait l’inverse et ouvre votre propre session derrière un écran de login GDM, que quelqu’un soit devant la machine ou non. Voir Ouvrir sa propre session (login).

Activer un hôte

Le bureau à distance est un opt-in explicite. Il s’active par la feature remote-desktop dans etc/config.yaml :

  - hostname: "clemence"
    profile: "umi"
    features: ["remote-desktop", "nfs-client"]

Puis just generate et just apply clemence. Un hôte sans cette feature ne peut pas être dépanné, et la configuration dit noir sur blanc lesquels le peuvent.

Groupes d’hôtes templatés

Une feature est héritée par tous les hôtes d’un groupe range: ou hosts:, ce qui couvre une famille entière de postes identiques en une ligne :

  - hostname: "fd-%'02s"
    profile: "desktop"
    range: [1, 2]
    features: ["monitoring-node", "nfs-client", "remote-desktop"]

C’est la raison du choix de features plutôt que de services : le bloc services: d’un groupe templaté n’est pas propagé aux hôtes générés.

Ce n’est pas anodin

Se rattacher à une session, c’est voir (et en rw piloter) l’écran de quelqu’un qui est probablement assis devant. GNOME affiche un indicateur de partage pendant toute la durée, mais rien ne demande son consentement. Réservez l’activation aux postes dont c’est l’usage assumé.

Les trois modes

Mode	Effet	Appliqué par
ro (défaut)	Vous voyez l’écran de l’utilisateur, vos entrées sont ignorées	Le serveur distant
rw	Le même écran, clavier et souris transmis	Le serveur distant
login	Un écran de login GDM, puis une session à vous

Le filtrage ro/rw est fait côté hôte, pas par le client : un client bricolé ne peut pas transformer un ro en rw.

ro et rw n’ouvrent jamais de session

Sans personne de connecté, ils n’ont aucun écran à refléter et échouent franchement. Demander à observer un utilisateur ne doit pas vous déposer ailleurs sans le dire, c’est login, et seulement login, qui ouvre une session neuve.

Raccourcis de la fenêtre

Le client est sdl-freerdp. Ses raccourcis utilisent Maj droite comme modificateur, et non Ctrl+Alt comme l’ancien client X11 :

Raccourci	Effet
Maj droite + Entrée	Plein écran (et retour)
Maj droite + G	Capture clavier/souris. Capturé, Alt+Tab et les autres raccourcis partent vers le poste distant ; relâché, ils reviennent au vôtre
Maj droite + R	Autoriser / bloquer le redimensionnement de la fenêtre
Maj droite + M	Réduire la fenêtre
Maj droite + D	Se déconnecter proprement

Revenir sur son poste

En plein écran avec la capture clavier active, Maj droite reste toujours interceptée localement : Maj droite + Entrée vous ramène, quoi qu’il arrive. Fermer la fenêtre désarme la session sur l’hôte.

Résolution et netteté

La fenêtre s’ouvre à la résolution native de l’écran distant : un pixel distant pour un pixel local, donc aucun rééchantillonnage et aucun flou.

Toute autre taille passe par une mise à l’échelle, qui adoucit l’image, c’est le prix du redimensionnement libre. Pour retrouver le 1:1 :

• Maj droite + Entrée : le plein écran est exact si votre écran a la même résolution que celui d’en face ;
• sinon, ramenez la fenêtre à sa taille d’ouverture.

Si l’écran distant est plus grand que le vôtre, la fenêtre dépasse et votre gestionnaire de fenêtres la contraint : l’image est alors réduite, donc adoucie. Le plein écran reste le meilleur compromis dans ce cas.

Ouvrir sa propre session (login)

just rd <hôte> login arme le démon système de gnome-remote-desktop et vous présente l’écran de login GDM. Vous vous authentifiez avec votre compte habituel, et GDM ouvre une session pour vous. C’est le mode à utiliser quand personne n’est connecté sur le poste, mais il fonctionne aussi bien quand quelqu’un l’est, sans rien changer à ce qui est affiché sur le moniteur.

Le démon système est déjà installé et inerte sur chaque hôte GNOME, exactement comme le démon utilisateur : rien de nouveau n’est ajouté, on l’arme puis on le désarme. Il est en outre le seul à savoir se passer d’un trousseau déverrouillé, ce qu’une machine où personne n’est connecté ne peut évidemment pas fournir.

Ce n’est pas l’écran de la machine

GDM ouvre une session neuve et sans écran, à côté de ce qui est affiché sur le moniteur. Vous ne voyez donc pas l’écran physique : vous êtes chez vous, pas chez quelqu’un d’autre. Pour dépanner un utilisateur, c’est ro ou rw qu’il faut.

Refléter le greeter GDM lui-même n’est pas possible : le démon utilisateur n’accepte ses identifiants que depuis un trousseau, et la session du greeter n’en a pas.

Bon à savoir : cette session-là est un moniteur virtuel, que le serveur peut redimensionner. C’est donc votre client qui impose la résolution, et l’affichage est net à 100 % sans réglage.

Ce qui se passe réellement

1. La commande joint l’hôte en SSH sous l’identité nix, comme toutes les commandes d’administration du parc.
2. Elle y arme la session : configuration du serveur RDP, certificat TLS éphémère, identifiants aléatoires à usage unique.
3. Elle monte un tunnel SSH vers le port RDP, resté fermé au réseau.
4. Elle lance le client FreeRDP sous votre propre compte, sur 127.0.0.1.
5. À la fermeture de la fenêtre, tout est désarmé et la configuration d’origine de l’hôte est restaurée.

Rien n’est jamais exposé sur le réseau : le pare-feu du parc reste en deny-by-default, aucune règle n’est ajoutée, même temporairement. Le serveur RDP n’écoute que le temps de la session, et le seul chemin pour l’atteindre est le tunnel.

Le certificat est auto-signé et régénéré à chaque session, dans la mémoire volatile de la machine. Son empreinte est relevée à travers SSH et épinglée dans le client : l’identité de la machine est donc garantie par le canal SSH lui-même, ce qui la lie plus étroitement qu’un nom de domaine certifié ne le ferait.

Sur l’écran de login, l’empreinte n’est pas épinglée : le démon système passe la main à la session de login, qui présente un certificat qui lui est propre. Épingler le premier casserait la seconde étape. C’est alors le tunnel, et lui seul, qui porte la confiance.

Fermeture automatique

L’hôte se désarme tout seul au bout de 60 minutes (réglable avec darkone.graphic.remote-desktop.timeout). Ce garde-fou couvre le cas où votre poste s’éteint, où le réseau tombe, ou où la commande est tuée brutalement : l’accès ne peut pas rester ouvert par accident.

Les trois moteurs

Le mode demandé et le type de la session ouverte déterminent le moteur.

Situation	Moteur	Ce que vous voyez
ro/rw, session GNOME Wayland ouverte	gnome-remote-desktop, démon utilisateur	L’écran de l’utilisateur
ro/rw, session Cinnamon X11 ouverte (postes UMI)	freerdp-shadow-cli sur l’affichage existant	L’écran de l’utilisateur
login	gnome-remote-desktop, démon système	GDM, puis votre propre session

Dans les trois cas : même protocole RDP, même client, même tunnel, même port.

Limites connues

• Une session à la fois par hôte. Une seconde tentative est refusée tant que la première n’est pas fermée.
• Plusieurs sessions graphiques ouvertes sur le même hôte : en ro/rw, la commande refuse de deviner et liste ce qu’elle a trouvé. login n’est pas concerné, il ne regarde pas les sessions existantes.
• Partage d’écran déjà activé sur la session cible : la commande n’y touche pas et s’arrête. C’est volontaire, une configuration posée à la main ne doit pas être écrasée puis « restaurée » de travers.
• Pas de son, pas de presse-papier partagé, pas de transfert de fichiers.
• Le redimensionnement manuel de la fenêtre ne respecte pas les proportions. La taille d’ouverture, elle, est correcte.
• gnome-remote-desktop est reconstruit sur les hôtes concernés (cf. la section suivante). Le build est mis en cache, mais un just update qui fait bouger GNOME peut faire échouer le patch, bruyamment.

Le pointeur de l’utilisateur

Tel qu’il est livré, gnome-remote-desktop transmet la forme du curseur mais jamais sa position quand il reflète un écran physique : le client dessine donc le curseur distant à l’emplacement de votre souris. En rw cela ne se voit pas puisque c’est vous qui le pilotez, mais en ro vous ne voyez pas du tout où l’utilisateur pointe, ce qui vide l’observation de son intérêt.

DNF corrige cela en patchant le serveur pour qu’il demande à mutter d’incruster le pointeur dans l’image (mode de curseur embedded, déjà utilisé en amont pour les moniteurs virtuels). Une ligne de code, et les métadonnées de curseur cessent d’être émises, donc aucun second curseur parasite.

Le prix est une recompilation locale de gnome-remote-desktop sur chaque hôte dépannable. Pour s’en passer :

darkone.graphic.remote-desktop.embedCursor = false;

En cas de problème

Symptôme	Cause probable
nobody is logged in	Personne n’est connecté : ro/rw n’ont rien à refléter, utiliser login
could not arm a … session	La feature remote-desktop n’est pas déclarée sur cet hôte, ou l’hôte n’a pas été redéployé
Failed to enable service: … EROFS	Hôte pas redéployé depuis l’ajout du mode login : just apply <hôte>
screen sharing is already enabled	Le partage GNOME a été activé à la main sur cette session
several active graphical sessions	Plusieurs comptes ont une session active sur le même poste
a support session is already open	Une session est réellement encore armée sur l’hôte : la fermer d’abord
no DISPLAY among the processes of session …	Session X11 dont le serveur X a disparu (session en cours de fermeture) : réessayer
the shadow server did not get port …	Le port RDP est déjà occupé sur l’hôte par autre chose
La fenêtre s’ouvre puis se ferme aussitôt	Vérifier que l’hôte est joignable et que le tunnel a pu se monter

Pour inspecter l’état côté hôte :

just enter clemence
sudo dnf-remote-desktop probe    # quelle session serait choisie
sudo dnf-remote-desktop stop     # désarmer manuellement