l'enfer c'est les autres
Récemment et contre tout bon sens, je me suis mis à offrir du support technique pour une utilisatrice GNU/Linux bidouillarde mais peu expérimentée. Mme Michu dispose d'une machine tournant sous une distribution avec laquelle je ne suis pas familier (Curvy Linux) qui a été installée par une personne qui n'est plus disponible.
Après le premier contact, il est vite apparu qu'il n'aurait pas été sain pour mon foie de me déplacer pour chaque intervention. D'où le besoin de mettre en place une solution de manipulation à distance. Mme Michu étant déjà habituée à une solution qui marche mais avec laquelle je m'interdit de contaminer mes machines, j'ai naturellement décidé de lui installer un truc plus compliqué et qui marche moins bien.
J'ai commencé par interroger un panel d'experts qui, dans leur grande sagesse, m'ont recommandé d'abandonner sans être capable de suggérer une piste de solution. Après avoir examiné la topologie locale ainsi que l'état de l'art, j'ai décidé qu'une solution à base d'OpenSSH me semble pas pire. Le reste de ce document décrit comment j'ai procédé.
salade de ports
Il y a trois machines en jeu : admin, serveur, client. La machine admin est mon poste de travail sur lequel je dispose d'un utilisateur et d'un client ssh. La machine serveur est une machine virtuelle nuagique disposant d'une adresse internet obsolète mais publique et sur laquelle j'ai le contrôle. La machine client est celle de Mme Michu.
Je veux réduire les risques qu'une présence malfaisante sur client puisse se propager à serveur ou admin et inversement. Je veux aussi donner à Mme Michu un semblant de contrôle sur quand j'accède à sa machine.
J'ai commencé par générer une clé SSH pour michu@client et à en copier la portion publique dans le ~/.ssh/authorized_keys de l'utilisatrice michu@admin fraîchement crée avec quelques restrictions :
no-agent-forwarding,no-pty,no-user-rc,no-X11-forwarding,command="/bin/sleep 31536000000000000",permitlisten="localhost:1337" ssh-rsa Ym9uam91ciBnZW50aWwgaGFja2VyIGRlIGxpbnV4ZnIK michu@client
En gros ça veut dire « autoriser uniquement le transfert de ports, n'autoriser à écouter que sur le port 1337 et déconnecter automatiquement après un milliard d'années ». Il y a bien un restrict qui permet d'activer toutes les restrictions mais il n'est apparemment pas possible de surcharger cette directive pour n'en autoriser qu'une (le transfert de ports). Ça veut aussi dire que la prochaine fois qu'OpenSSH implémente une nouvelle fonctionnalité associée à une directive no-*, il faudra penser à ajouter cette dernière explicitement.
Du côté client, j'ai installé un serveur OpenSSH qui n'écoute que sur les adresses de la boucle locale :
ListenAddress localhost
Je me suis crée un compte krunch@client sur lequel j'ai copié ma clé SSH publique et que j'ai ajouté aux sudoers.
J'ai aussi ajouté ceci dans le ~/.ssh/config de michu@client :
Host serveur
HostName serveur.example.com
RemoteForward localhost:1337 localhost:22
L'idée est qu'une fois la connexion ssh établie, le port 1337 sur serveur sera transmis au port 22 sur client. Le HostName permet aussi d'économiser un peu les doigts de Mme Michu.
Du côté admin, il me reste juste à ajouter ceci à mon ~/.ssh/config :
Host client
HostName localhost
Port 1337
ProxyJump serveur.example.com
La subtilité vient de la toute nouvelle directive ProxyJump introduite dans OpenSSH 7.3 en 2016. Le client ssh se connecte d'abord à serveur, établi un tunnel TCP vers le port 1337 de serveur puis se connecte via ce tunnel. C'est un peu comme ForwardAgent / -A mais sans avoir à faire confiance à serveur.
En image, ça donne ceci :
┌──────┐ ┌──────────┐ ┌─────┐
│client│ │ serveur │ │admin│
│ │ │ │ │ │
│ ───├──►22 │ │ │
│ │ │ │ │ │
│ │ │┌───────22◄──┤─── │
│ │ ││ │ │ │
│ │ │└─►1337──┐│ │ │
│ │ │ ││ │ │
│ 22◄──│──│─────────┘│ │ │
│ │ │ │ │ │
└──────┘ └──────────┘ └─────┘
après l'effort, l'effort suivant peut commencer
Maintenant, lorsque Mme Michu m'appelle pour que je l'aide avec le pilote de sa nouvelle carte wifi, je peux lui demander de taper ssh serveur dans son coquillage, suite à quoi il me suffit d'exécuter ssh client pour être connectée chez elle.
colophon
Pour des raisons évidentes de respect de la vie privée, les nom des machines, des distributions GNU/Linux ainsi que les numéros de ports ont été modifiés, sauf localhost et 22 pour des raisons d'intelligibilité.
# illustration
Posté par Krunch (site web personnel) . Évalué à 4 (+3/-1). Dernière modification le 29 novembre 2025 à 12:20.
Malheureusement DLFP ne semble pas à la pointe de la technologie en ce qui concerne le rendu des caractères ASCII. J'ai ouvert un suivi. En attendant qu'il soit traité (aussitôt après que le bogue précédent sur le sujet que j'ai ouvert en 2014 sera corrigé j'imagine), vous pouvez consulter l'illustration dans toute sa gloire originelle via le lien dans le journal que je recopie ici avec une correction mineure.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: illustration
Posté par MicP . Évalué à 3 (+2/-0). Dernière modification le 29 novembre 2025 à 13:09.
Bonjour
J'avais déjà eu le même problème sur d'autres types de forums.
Ici, ce n'est pas le rendu des caractères ASCII, mais la hauteur de ligne qui fait 1.5em et qu'il faudrait mettre à 1em pour que les traits verticaux de ton diagramme soient joints.
Mais ça risque sûrement d'impacter d'autres éléments, et ça serait peut-être un trop gros boulot d'analyse à faire de tous les fichiers css pour pas grand-chose
puisque ton diagramme ascii est quand même parfaitement lisible.
Cordialement.
… et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.
[^] # Re: illustration
Posté par MicP . Évalué à 1 (+0/-0).
Pour tester la modification qui permettrait d'afficher correctement ton diagramme.
Avec Firefox :
Click droit sur ton diagramme => affichage d'un menu contextuel
Click dans le menu contextuel sur l'option "Inspecter"
Chercher le sélecteur css "pre code"
y ajouter la propriété suivante :
line-height:1em;Le diagramme s'affichera alors comme tu le voudrais.
Mais si cette même règle était appliquée pour toutes les pages du forum,
les lignes de code affichées (ça se voit surtout avec les lettres en majuscule) seront collées l'une à l'autre.
Donc, même si l'ajout de cette propriété css fonctionne bien pour faire apparaître ton diagramme correctement
ça va rendre affreux l'affichage de tous les scripts et autres lignes de texte qui sont dans une balise code.
… et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.
# RustDesk ?
Posté par Cascador (site web personnel) . Évalué à 10 (+10/-1).
Salute,
J'utilise RustDesk depuis quelques temps, avant je contaminais mes machines avec TeamViewer (devenu pénible).
Tcho !
# Rustdesk ?
Posté par damiend . Évalué à 4 (+4/-1).
Rustdesk est libre et fonctionne comme Teamviewer.
[^] # Re: Rustdesk ?
Posté par sc-b303 . Évalué à 4 (+4/-0).
Bonjour
J'utilise rustdesk aussi, pour aider ma belle mère à distance.
Une fonctionnalité appréciable,mais à utiliser avec précaution : la connexion à distance sans la permission de la belle mère, en prenant le contrôle sur l'écran de login (lightdm)
Utile quand la belle mère ne sait plus taper son mot de passe ! Elle peut voir toutes mes actions et aussi interagir sur l'écran.
Elle a 75 ans et grande débutante sur tout type d'ordinateur. Félicitations à elle pour sa persévérance.
# DWService ?
Posté par PLuG . Évalué à 1 (+0/-0). Dernière modification le 29 novembre 2025 à 15:56.
Je fais aussi du support à distance pour mon père en particulier, qui est sous fedora.
J'utilisais openssh, ou même openvpn, j'ai testé aussi tmate mais le besoin de partager la même vision de l'écran est necessaire de temps en temps pour le guider dans des manips, lui apprendre comment il aurait du faire par lui même…
Pendant une periode j'utilisais teamviewer, mais j'ai arrêté quand ils ont changé les conditions d'usage.
finalement j'ai choisi DWService. il y a un client à lancer sur le PC sur lequel on veut prendre la main, et coté "admin" il suffit d'utiliser un navigateur. ça juste marche.
Je ne connaissais pas rustdesk, j'y jetterai un oeil.
# gitso ?
Posté par GaMa (site web personnel) . Évalué à 2 (+0/-0).
Il y a un temps, j'utilisais gitso (qui n'a pas été mis à jour depuis 11 ans par contre…)
Pas de serveur et très peu de configuration côté Michu. C'est du côté admin où il faut ouvrir les bons ports sur une IP publique.
On donne l'IP de l'admin, Michu rentre cette adresse dans l'app et c'est tout.
Matthieu Gautier|irc:starmad
# OpenVPN, KRFB+KRDC
Posté par vpinon . Évalué à 3 (+1/-0).
Ma freebox a un serveur OpenVPN, j'ajoute des comptes aux personnes que je dépanne (et leur charge le .ovpn quand je leur fait leur install).
Besoin d'aide ? "cliquer sur le bouclier dans la liste des WiFis" et elles sont sur mon réseau local.
Si je peux m'en sortir en SSH (quand j'ai un compte ou une clé sur leur machine) ça suffit.
Sinon manip 2 de leur côté "lancer KRFB et me donner le mot de passe à usage unique", KRDC de mon côté et voilà.
Effectivement RustDesk est censé intégrer tout ça en 1, mais pas encore testé…
# nebula
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 30 novembre 2025 à 12:08.
J'aurais utilisé nebula, un outil de vpn maillé avec aussi 3 noeuds dont un accessible via une adresse ip publique.
Un simple script utilisant zenity/yad pour avoir un peu de gui et executable via un fichier .desktop pour cette personne qui ne se connecte au réseau nebula que quand elle a besoin d'aide et toi après tu peux accéder à sa machine via ssh/vnc/rdp/moonlight ou que sais-je.
# zerotier, nomachine
Posté par tkr (Mastodon) . Évalué à 2 (+0/-0).
pour ceux qui peuvent faire de l'auto hébergement, je recommande rustdesk.
Mais:
si l'idée est d'intervenir sur un windows distant, teamviewer/anydesk ne sont pas si mal. Ils fonctionnent.
Mais :
si vous pouvez avoir un VPN pour vous relier, sans passer par ces deux services, voilà comment je fais, valable sous win/nux :
-crééer un tunnel vpn chez zerotier
-faire installer le vpn chez la personne, et l'autoriser sur le vpn
-joindre via NoMachine, l'adresse zerotier de la personne
je fais ca en ipv6 avec du lien local depuis six mois, ça fonctionne. Nomachine, en version gratuite, se base sur du SSH.
le seul pépin, c'est que pour un windows avec session sans mdp, ça passe pas :D
[^] # Re: zerotier, nomachine
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
Pourquoi utiliser un outil propriétaire (nomachine) plutôt que ses pendants libres freenx ou x2go?
Je crois qu'à l'heure où beaucoup de bureaux proposent wayland par défaut, ces solutions ne vont de toute façon pas marcher partout.
[^] # Re: zerotier, nomachine
Posté par tkr (Mastodon) . Évalué à 2 (+0/-0).
x2go j'en ai entendu parler, c'est surtout orienté grands réseaux et corporates, amha
freenx semble être l'ancetre de nomachine, non maj depuis au moins dix ans.. tous les tutos datent d'avant 2010…
voilà pourquoi..
# Liens
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0).
Solution un peu complexe mais laissant le sentiment du travail accompli !
De mon côté, j'ai adoré suivre tes liens 😉.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.