Ce qui suit est une mise en œuvre basique de l’outil de prise en main à distance MeshCentral. Adapté pour les petits dépannages mais conçu pour les organisations, c’est une solution à évaluer face aux logiciels plus connus comme TeamViewer, AnyDesk ou RustDesk. Je (NdM: YvanM) me garderai cependant de faire un comparatif des fonctionnalités, car je ne connais pas assez cet outil et ses « concurrents ».

Sommaire

• MeshCentral c’est quoi ?
• Installation du serveur
  • Premier lancement
  • Configuration DNS et IP
  • Installation du certificat TLS
  • Configuration textuelle de MeshCentral
  • Création du quadlet
• Utilisation de MeshCentral
  • Première connexion
  • Installation de l’agent
    • Pour Windows
    • Pour Linux
    • Avec une invitation
  • Mise à jour de l’agent
  • Utilisation avec Wayland
    • Avec Gnome
    • Avec KDE

MeshCentral c’est quoi ?

MeshCentral propose des fonctionnalités similaires à TeamViewer ou AnyDesk. C’est à ma connaissance le seul outil complètement libre de ce type (il est sous licence Apache 2.0). RustDesk est également régulièrement cité sur LinuxFR, mais c’est un logiciel « open core », on peut donc être rapidement limité avec la version libre selon les usages souhaités.

Le projet était, si ma mémoire est bonne, sponsorisé par Intel dans ses débuts. Il est toujours en développement, mais il n’y a visiblement qu’un seul mainteneur actif. Cette personne semble proposer le développement sponsorisé de fonctionnalités.

Malgré cette confidentialité, MeshCentral propose presque toutes les fonctionnalités qui me semblent nécessaires pour une utilisation en entreprise. Il est également adapté à mes besoins en tant que particulier qui dépanne ponctuellement la famille et les amis :

• La partie serveur est libre et s’installe sur un serveur Linux (on peut aussi sur Windows) ;
• Le client supporte Windows, Linux, MacOS, FreeBSD et Android, sur plusieurs architectures matérielles ;
• La personne qui « prend la main » n’a pas de client à installer, tout se fait par l’interface web du serveur (ce n’est pas forcément un avantage, c’est juste pour expliquer comment ça s’utilise) ;
• Il n’y a pas besoin de configurer le client pour qu’il pointe vers votre serveur, il suffit de le lancer ou de l’installer ;
• Quand on prend la main sur les clients, on a accès :
• Au bureau ;
• À un shell ;
• À une fonctionnalité de transfert de fichiers ;
• Des informations sur le matériel ;
• On peut se servir d’une machine sur laquelle le client est installé comme « rebond » pour accéder en RDP, VNC, HTTP et HTTPS aux autres machines qui sont sur le réseau du client ;
• Le client permet un accès permanent ou à la demande ;
• On peut créer des groupes de machines ;
• On peut avoir plusieurs utilisateurs sur le serveur, avec des permissions différentes ;
• Il permet l’authentification multi-facteur ;
• Il supporte l’authentification locale, SAML, JumpCloud, Azure, GitHub, Google, SSO avec OpenID Connect… ;
• On peut personnaliser le client et l’interface web ;
• Il est multitenant ;
• Il peut utiliser Intel AMT (je n’ai jamais essayé) : « when available, administrators can remotely power on, boot to BIOS and manage a system regardless ofthe operating system state. ». Je m’étais d’ailleurs dit que ça devait être une raison du support d’Intel pour ce projet ;
• Et un paquet d’autres choses que je ne détaillerai pas.

J’ai une utilisation très restreinte de l’outil, mais j’ai quand même constaté des limitations embêtantes :

• Il n’est pas possible d’accéder au bureau distant si celui-ci utilise Wayland. Si je comprends bien il faudrait un développeur C qui connaisse Wayland, à bon entendeur ;-). Plusieurs contournements sont possibles :
• Utiliser l’accès en ligne de commande uniquement, c’est parfois suffisant ;
• Expliquer à l’utilisateur de rouvrir sa session sous Xorg ;
• Lancer un serveur RDP ou VNC sur le client, et utiliser le client RDP ou VNC intégré à l’interface web de MeshCentral (voir les suggestions en bas de cette dépêche).
• En mode « à la demande » sous Windows, je n’arrivais pas à avoir la main sur les fenêtres lancées en tant qu’administrateur. Ça a peut-être changé depuis la dernière fois où j’ai testé (en 2023) ;
• Je trouve que la documentation n’est pas super, il ne faut donc pas hésiter à aller voir les vidéos qui couvrent beaucoup de sujets.

Installation du serveur

La méthode d’installation dépendra forcément du contexte. Voilà le mien :

• Je veux que le serveur soit sur mon ordinateur portable (actuellement sous Debian 13). Je n’ai pas de serveur à la maison et je n’ai pas envie de gérer une machine en plus. L’inconvénient c’est que je ne pourrais utiliser MeshCentral qu’à la maison, car j’aurais un enregistrement DNS qui pointera vers l’IP de ma box ;
• Je veux faire tourner le serveur avec Podman dans un conteneur « utilisateur » (parce que même si j’ai pris l’habitude de Docker, j’ai envie de tester Podman).

En termes de RAM et d’utilisation CPU je ne me fais pas de soucis : pour les petites installations c’est censé tourné sur Raspberry Pi. Effectivement, le serveur démarré et un client connecté, le serveur consomme 90 Mo de RAM et 1 % de CPU (j’ai un i5-4300U, soit 4 cœurs à 1.90GHz)

Premier lancement

On installe podman :

sudo apt install podman

On crée l’utilisateur dédié nommé meshcentral (je trouve intéressant sur le principe d’avoir un utilisateur par service) qui fera tourner le conteneur, et on en profite pour mettre son home dans /srv (car ce n’est pas un utilisateur « normal ») :

sudo useradd --base-dir /srv \
--create-home \
--shell /bin/bash \
--user-group \
meshcentral

On note que par défaut useradd (tout comme adduser d’ailleurs) ajoute automatiquement une plage de sous-UID et sous-GID dans /etc/subuid et /etc/subgid : ces plages seront utilisées par les conteneurs que l’utilisateur meshcentral lancera (voir man 5 subuid).

Dans mon cas je démarrerai le service à la main quand j’en ai besoin, mais si on voulait que notre service puisse démarrer automatiquement à l’allumage de la machine il faudrait en plus exécuter la commande suivante :

sudo loginctl enable-linger meshcentral

On se connecte en tant que meshcentral :

sudo --login --user meshcentral

Il existe sur le Docker Hub des images de MeshCentral, mais je n’en vois pas d’officielles et j’ai envie de bricoler :-). En me basant sur la documentation d’installation, on crée donc un fichier /home/meshcentral/Containerfile (équivalent d’un Dockerfile) avec le contenu suivant :

# On se base sur Debian Trixie en version slim
FROM docker.io/library/debian:trixie-slim

# On définit que la version « latest » de MeshCentral sera installée par défaut
ARG MESHCENTRAL_VERSION="latest"

# On fait les mises à jour, on installe les logiciels nécessaires, puis on
# supprime le cache des paquets
RUN apt-get update \
&& DEBIAN_FRONTEND=noninteractive apt-get full-upgrade --assume-yes \
&& DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends --assume-yes nodejs npm tini \
&& rm -r /var/cache/apt/*
# On crée un utilisateur dédié pour lancer le service
RUN useradd --shell /usr/sbin/nologin --user-group --create-home meshcentral
# On utilise ce nouvel utilisateur
USER meshcentral
# On se place dans le bon répertoire
WORKDIR /home/meshcentral
# On installe les dépendances de MeshCentral dans ce répertoire
RUN npm install meshcentral@${MESHCENTRAL_VERSION}
# On définit la variable d’environnement conseillée pour faire tourner node
# en production
ENV NODE_ENV=production
# On lance tini pour qu’il prenne en charge et relaie SIGTERM
ENTRYPOINT ["tini","--"]
# Et finalement on lance meshcentral
CMD ["node","./node_modules/meshcentral"]

On construit ensuite l’image, ici en précisant la version stable de MeshCentral qu’on veut récupérer du dépôt NPM et en appliquant un tag :

podman image build --build-arg MESHCENTRAL_VERSION=1.1.55 --tag meshcentral:1.1.55.

L’image est stockée dans ~/.local/share/containers/storage/overlay/. podman image ls m’indique qu’elle fait 976 Mo.

On crée les volumes :

podman volume create meshcentral-files # pour les fichiers qu’on veut transmettre depuis ou vers les clients
podman volume create meshcentral-data # pour la configuration, les certificats, etc.

Ils se trouvent comme on peut s’y attendre dans ~/.local/share/containers/storage/volumes/.

On fait un premier lancement à la main, ce qui permet de créer le fichier de configuration par défaut et de tester si ça marche. On n’est pas root, donc on ne pourra pas utiliser le port 443. De plus, dans le conteneur MeshCentral ne tourne pas en tant que root et utilisera donc par défaut le port 1025 :

podman run --rm \
--volume=meshcentral-data:/home/meshcentral/meshcentral-data \
--volume=meshcentral-files:/home/meshcentral/meshcentral-files \
--publish 1025:1025/tcp \
--hostname meshcentral \
--name meshcentral \
localhost/meshcentral:1.1.55

Depuis le navigateur web, on peut aller sur https://127.0.0.1:1025 pour s’assurer que le service est accessible. Mais revenons pour l’instant dans le terminal et arrêtons notre conteneur avec Ctrl+C

Comme MeshCentral n’est pas joignable sur le port 80, on ne peut pas utiliser le client Let's Encrypt intégré pour obtenir un certificat. On va donc obtenir un certificat manuellement avec certbot.

Configuration DNS et IP

Sur mon nom de domaine, j’ajoute un enregistrement A aide.domain.example qui pointe vers l’adresse IPv4 de ma box. J’aurais bien aimé faire de l’IPv6 aussi, mais avec le pare-feu IPv6 de ma box Free c’est soit on ouvre tout, soit on ferme tout…

Côté box, j’ajoute une redirection de ports pour que les ports TCP 80 et 1025 arrivent sur l’adresse IPv4 de mon laptop. J’ai également configuré un bail statique sur ma box pour que mon ordinateur portable ait toujours la même adresse IP.

Installation du certificat TLS

On reprend notre utilisateur standard pour installer certbot :

sudo apt install certbot

On lance la commande suivante pour tester l’obtention d’un certificat. Il faudra renseigner une adresse e-mail (utilisée pour prévenir lorsque le certificat expire bientôt) et valider les conditions d’utilisation :

sudo certbot certonly --standalone --domain aide.domain.example --dry-run --test-cert

Si ce premier essai marche, on peut demander un certificat de test. C’est utile pour s’assurer qu’on a bien tous les bons paramètres, car Let's Encrypt applique des limites pour les demandes de certificats valides. On doit demander un certificat RSA (et non ECDSA par défaut) car MeshCentral ne sait pas encore gérer ECDSA. On va aussi utiliser l’option --deploy-hook pour copier le certificat au bon emplacement et avec les bonnes permissions. Le propriétaire de ces fichiers doit correspondre avec l’UID de l’utilisateur à l’intérieur de notre conteneur, sinon la clé privée ne sera pas lisible par MeshCentral. On peut pour cela regarder quel est l’UID des fichiers dans notre volume (/srv/meshcentral/.local/share/containers/storage/volumes/meshcentral-data/_data/), pour le reporter 4 fois dans la commande ci-dessous (dans mon cas 232071). Attention également à adapter le nom de domaine (à 3 endroits) :

sudo certbot certonly --test-cert \
--key-type rsa \
--standalone \
--domain aide.domain.example \
--deploy-hook 'install --verbose --owner=232071 --group=232071 --mode=644 /etc/letsencrypt/live/aide.domain.example/fullchain.pem /srv/meshcentral/.local/share/containers/storage/volumes/meshcentral-data/_data/webserver-cert-public.crt; install --verbose --owner=232071 --group=232071 --mode=600 /etc/letsencrypt/live/aide.domain.example/privkey.pem /srv/meshcentral/.local/share/containers/storage/volumes/meshcentral-data/_data/webserver-cert-private.key'

Si tout se passe bien, on peut exécuter la même commande mais sans l’option --test-cert et on aura cette fois un certificat valide. Celui-ci est valable 3 mois, et par défaut est renouvelé automatiquement par le service systemd certbot.service déclenché par le timer certbot.timer. Comme je suis sur un laptop et que ce renouvellement ne peut fonctionner que si je suis chez moi, je désactive l’exécution automatique :

sudo systemctl disable certbot.timer

Quand j’aurais besoin de renouveler le certificat et que je serai à la maison, j’aurais simplement à faire sudo systemctl start certbot.service (enfin c’est comme ça que j’ai compris le mécanisme, je n’ai pas testé).

Configuration textuelle de MeshCentral

On va maintenant modifier le fichier de configuration qui a été généré au premier démarrage de MeshCentral. Depuis l’hôte, en tant que l’utilisateur meshcentral, la solution la plus simple est de lancer podman unshare vim ~/.local/share/containers/storage/volumes/meshcentral-data/_data/config.json. Ça permet d’être dans le bon namespace pour avoir les droits d’écriture sur le fichier. On pourrait aussi utiliser notre compte root de l’hôte mais c’est intéressant de connaître l’existence de podman unshare qui semble bien utile pour comprendre et résoudre des problèmes.

Dans mon cas j’ajoute simplement les directives suivantes sous settings. On peut laisser les commentaires déjà présents dans le fichier. Les curieux iront lire la documentation (par exemple ici) pour voir tout ce qu’il est possible de faire :

• "cert": "aide.domain.example" pour indiquer comment MeshCentral est joignable ;
• "port": "1025" pour spécifier le port plutôt que de prendre le premier disponible ;
• "WANonly": true parce que les fonctionnalités de LAN ne m’intéressent pas ;
• "amtManager": false parce que je ne vais pas me servir d’AMT (je ne sais pas si ça marche vraiment parce qu’il écoute toujours sur le port 4433, mais ça n’est pas gênant, car le port n’est pas exposé sur l’hôte).

On peut relancer MeshCentral pour s’assurer que ça fonctionne.

Création du quadlet

Bien que Podman supporte les fichiers docker-compose.yml (si on installe le paquet Debian podman-compose), il cherche avant tout à s’intégrer au mieux avec systemd. Pour ça il propose les quadlets (voir man 5 quadlet), qui sont un type d’unités systemd qui permettent de faire à peu près la même chose qu’un fichier docker-compose.yml. On va utiliser cette méthode pour faciliter le lancement ultérieur de notre conteneur. Ici, je vais placer mon unité systemd dans le répertoire de mon utilisateur meshcentral. On crée le bon répertoire :

mkdir --parents ~/.config/containers/systemd/

Et on y crée le fichier ~/.config/containers/systemd/meshcentral.container avec le contenu suivant :

[Unit]
Description=Meshcentral in a Podman container
# C’est déjà une dépendance implicite, mais je la mets pour que ce soit explicite
After=networking.target

[Container]
Image=localhost/meshcentral:1.1.55
ContainerName=meshcentral
HostName=meshcentral
PublishPort=1025:1025
Volume=meshcentral-files:/home/meshcentral/meshcentral-files
Volume=meshcentral-data:/home/meshcentral/meshcentral-data
# Je ne sais pas si c’est c’est vraiment utile mais ça ne coûte rien
DropCapability=all

On indique à systemd de prendre en compte ce nouveau fichier :

systemctl --user daemon-reload

Et on peut démarrer notre service simplement :

systemctl --user start meshcentral.service

Utilisation de MeshCentral

Première connexion

Passons enfin à l’utilisation de MeshCentral. Depuis la page d’accueil de l’interface web, cliquer sur le lien pour créer un premier compte utilisateur.

Une fois connecté, cliquer sur le lien « Créer un nouveau groupe d’appareils ». Pour mon usage basique, je laisse comme type « Gérer à l’aide d’un agent logiciel ».

Installation de l’agent

Il faut maintenant obtenir et installer le client (ici appelé « agent ») sur les postes, et quand on clique sur « Ajouter un agent » à côté du nom du groupe il y a pléthore de choix.

Pour Windows

Pour Windows, je ne saurais pas dire exactement quels choix permettent quelles fonctionnalités (installation en tant que service, assistance à la demande sans que l’utilisateur ait les droits d’administration…) car je n’ai plus de machine pour tester, désolé.

À noter que par défaut l’agent n’est pas signé, donc Windows demande une confirmation avant d’exécuter le binaire.

Pour Linux

Pour Linux, on obtient un agent à installer en tant que service en choisissant « Exécutable d’installation Linux / BSD / macOS », avec « Type d’installation » « Ligne de commande & bureau distant » ou « Ligne de commande uniquement », puis en cliquant sur le lien nommé « MeshAgent ». Il faudra alors faire une commande du type chmod +x && sudo./meshagent pour l’installer (ajouter l’option -install à meshagent pour éviter la pop-up graphique qui demande quoi faire).

L’agent sera installé dans /usr/local/mesh_services/meshagent/meshagent et sera lancé automatiquement par le service meshagent.service. Pour le désinstaller il est possible de supprimer ces fichiers, ou d’utiliser le binaire de désinstallation téléchargeable également depuis l’interface web, toujours via le lien « Ajouter un agent », ou de lancer le binaire installé avec l’option -uninstall.

On obtient un agent que l’utilisateur sans droit root pourra utiliser en choisissant « Exécutable d’installation Linux / BSD / macOS », avec « Type d’installation » « Interactif seulement » (pas vraiment instinctif…). Il faudra dans tous les cas bien expliquer à cet utilisateur comment démarrer ce binaire (car ça dépend de l’environnement qu’il utilise et parce qu’il faut ajouter les droits d’exécution), mais une solution est de lui donner par e-mail une commande toute prête à copier-coller dans son terminal, du type :

cd /tmp/ && wget -O meshagent « https://aide.domain.example:1025/meshagents?id=pYWSORfgTMN%2IdKohzytKQePtv8DzNzbTZcqB2m%24h7MuA4bzXSWJRt6vLN9VBILW&installflags=1&meshinstall=6 » && chmod +x meshagent &&./meshagent

Pour une utilisation à la demande, je m’étais créé un paquet Debian qui une fois installé, permettait par un clic de l’utilisateur de télécharger le binaire et de le lancer, le tout avec une interface graphique basique. C’était de loin le plus simple pour les utilisateurs, mais c’est pas mal de travail.

Avec une invitation

Les méthodes d’installation ci-dessus nécessitent que vous transmettiez le binaire (ou le lien de téléchargement précis) aux utilisateurs. Une autre méthode consiste à inviter les utilisateurs ce qui crée une URL spécifique, accessible sans identifiant, pour qu’ils puissent eux-mêmes télécharger le binaire et obtenir les instructions d’installation. Pour cela, depuis la page d’accueil, cliquer sur le lien « Inviter » à côté du nom du groupe.

C’est à mon sens particulièrement intéressant pour les utilisateurs Windows, puisqu’il suffit de leur transmettre le lien par courriel. (NdM: attention à ne pas habituer les utilisateurs à installer tout et n'importe quoi en un clic sur un lien, en particulier un outil de prise en main à distance. Optez pour un canal de confiance, un courriel signé, etc.)

Mise à jour de l’agent

La mise à jour des agents se fait automatiquement (si nécessaire) après redémarrage du serveur sur une nouvelle version.

Utilisation avec Wayland

Comme dit plus haut, l’agent MeshCentral n’est pas encore compatible Wayland. Voici quelques idées de contournement qui peuvent convenir à votre cas d’usage, ou pas.

Pour avoir accès au gestionnaire de session, j’imagine qu’il suffirait de lancer ce dernier avec Xorg, mais je n’ai jamais testé.

Pour avoir accès à la session on peut en général indiquer à l’utilisateur comment rouvrir sa session avec Xorg. Mais rappelons-nous également que MeshCentral peut se connecter à un serveur RDP ou VNC qui tourne sur la machine, ce qu’on peut faire assez facilement.

Avec Gnome

Si c’est Gnome qui tourne on peut simplement lancer le serveur VNC intégré. On peut indiquer à l’utilisateur de le faire, mais on peut aussi le faire nous-même depuis l’accès en ligne de commande proposé par MeshCentral. À noter que ce serveur VNC écoute sur toutes les interfaces réseau et que même si un mot de passe aléatoire est défini, il est recommandé de l’arrêter lorsque l’accès distant au bureau n’est plus nécessaire :

# on enregistre comment accéder à dbus (nécessaire pour dconf et systemctl
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/"$(id --user)"/bus
# on désactive l’accès RDP qui est activé par défaut
dconf write /org/gnome/desktop/remote-desktop/rdp/enable false
# on active l’accès VNC qui est désactivé par défaut
dconf write /org/gnome/desktop/remote-desktop/vnc/enable true
# on démarre le service utilisateur de partage du bureau
systemctl --user start gnome-remote-desktop.service

Avec KDE

Une solution est d’utiliser le serveur VNC Krfb, qu’on installera avec une commande du type sudo apt install krfb. Il suffit ensuite de demander à l’utilisateur de démarrer ce logiciel depuis le menu (il se trouve dans la rubrique « Internet » et qu’il vous communique le mot de passe.

Comme pour le cas de Gnome juste au-dessus, je recommande également d’arrêter Krfb une fois la prise en main à distance terminée (depuis le menu « Fichier -> Quitter », parce que cliquer sur la croix ferme juste la fenêtre).