Imaginons que Alice veuille se faire dépanner par Bob.
Problème, Bob ne peut pas se connecter directement à l’ordinateur d’Alice à cause d’un routeur NAT (une box ADSL, un réseau d’entreprise, un réseau wifi public, etc…).
Il existe un moyen assez simple pour Alice de se faire dépanner grâce à SSH.
Bob a un peu de travail avant
Bob va créer sur sa machine un utilisateur aux droits très restreints. Alice va utiliser celui-ci pour faire un tunnel inversé. On commence par la création du nouvel utilisateur dénommé « help » :
# adduser help
Dans /etc/ssh/sshd_config faites un règle spéciale pour cet utilisateur :
Match User help #AllowTcpForwarding yes X11Forwarding no PermitTunnel no GatewayPorts no AllowAgentForwarding no PermitOpen localhost:60000 ForceCommand echo 'Only reverse port forwarding allowed'
En gros, l’utilisateur ne peut qu’écouter sur le port 60000 local.
Authentification par clé de chiffrement
Bob doit avoir une paire de clés de chiffrement SSH.
Ensuite il doit transmettre sa clé publique à Alice. Pour cela, Bob doit envoyer son fichier ~/.ssh/id_rsa.pub à Alice.
Alice doit vérifier avec Bob que la clé reçue est bien la bonne. Pourquoi? Parce qu’Alice va maintenant autoriser le détenteur de la clé privée correspondante (Bob logiquement) à se connecter à son compte avoir son mot de passe. Pour cela, Alice doit ajouter le contenu du fichier « id_rsa.pub » à son fichier ~/.ssh/authorized_keys:
$ echo id_rsa.pub >> ~/.ssh/authorized_keys
Note, le fichier ~/.ssh/authorized_keys doit se terminer par un ligne vide.
Alice doit ensuite copier-coller ceci en dans un terminal en remplacant l’IP de Bob:
$ ssh -N -R 60000:localhost:22 help@ip_de_bob
L’empreinte de la clé publique de la machine de Bob sera présentée. Tapez « yes ».
Le mot de passe à entrer est donné par Bob, c’est celui de l’utilisateur « help » que Bob a créé chez lui. Note pour Alice : le mot de passe ne s’affiche pas quand on le tape, c’est normal :)
Voila. c’est fini pour Alice.
Prise de contrôle
Bob peut ensuite se connecter à l’ordinateur d’Alice, sous le compte d’Alice sans connaitre le mot de passe d’Alice :
$ ssh -p 60000 alice@localhost
Critique
Cette technique est une alternative à Teamviewer pour Linux et Mac. Elle permet notamment d’avoir un accès confortable au terminal à distance et aux possibilités évoluées de SSH par la suite (partage de fichier par SFTP, redirection de port, proxy SOCKS pour naviguer sur le réseau local, VNC sécurisé, etc…).
Au début, je me suis dit que j’allais enfin tordre le cou au « man in the middle » de Teamviewer. Mais en réalité, il y a pas mal de failles de sécurité dans la mise en place de ce processus.
Premièrement, Alice doit vérifier et ajouter la clé publique de Bob. Pas facile ! Aussi, elle donne l’accès à ses fichiers pour se faire aider et n’aura aucun contrôle sur ce que fera Bob avec cet accès. Donc il faut une grande confiance dans Bob.
Ensuite, par quel canal est transmis la commande à taper? la clé publique de Bob? Comment est vérifiée l’authentification de la machine de Bob par Alice?
Il y a peut être moyen de wrapper tout ça dans un utilitaire avec une double authentification et une interface graphique qui affiche sur l’écran d’Alice un suivi en temps réel des commandes effectuées par Bob, des fichiers transférés… le tout sans nécessiter le mot de passe de session d’Alice. Mais ce sera peut être moins flexible pour Bob… (auto-complétion, sshfs, etc..)
La commande à taper est publique, donc aucun soucis de transmission de donnée à ce niveau. Et côté mot de passe, on peut passer par des clés publiques. C’est simple et ne nécessite pas de canal sécurisé.
Et pas l’inverse bien sûr ………
@Ann Aarxist : Ça m’a aussi un peu fait tiquer (surtout le titre) mais ça m’étonnerais que ce soit volontaire…
Problème : NAT des deux côtés.
en voyant le titre j’ai pensé au script de Rom1 :
http://blog.rom1v.com/2014/06/sshfs-inverse-rsshfs/
@karchnu : c’est vrai que Bob pourrait ajouter la clé publique d’Alice au clés autorisées à se connecter en tant qu’utilisateur « help » sur sa machine
Et Alice pourrait autoriser la clé publique de Bob à pouvoir se connecter sur sa machine.
Je mettrai à jour le tutorial quand j’aurais l’occasion.
@matlink : si tu es le geek tu sais ouvrir un port sur le NAT non? Tu n’as pas le contrôle sur ton NAT chez toi?
Ça pourrait être intéressant… Dommage que ce soit ouvertement sexiste
http://bohwaz.net/static/Encourage-Women-Linux-HOWTO-fr.txt
La meilleure solution que j’ai trouvée et que j’utilise fréquemment est Gitso (https://code.google.com/p/gitso), outil multi-plateformes sous licence GPL v3. Malheureusement, le projet n’est plus actif depuis 2010 et qui plus est hébergé chez Google — il risque donc de disparaître avec le service Google Code si personne ne l’exporte sur GitHub ou ailleurs.
Néanmoins, Gitso reste parfaitement utilisable et très simple à manipuler. Celui qui veut apporter du support doit ouvrir un port de son coté ; rien de plus simple pour lui. Ensuite, proposer de l’aide est enfantin. Il suffit à celui qui offre du support de lancer Gitso avec l’option « give support », et à celui qui en fait la demande d’entrer le nom de domaine du premier — ou son adresse IP. Ensuite, c’est du VNC.
Si quelqu’un était intéressé pour entretenir le projet, ce serait vraiment salutaire.
@cypouz : vraiment, l’usage de VNC like est superflue dans la quasi totalité des cas.
Et je ne ferai que moyennement confiance en un soft qui n’a pas été mis à jour depuis 5 ans. S’il y a une réelle utilité à faire du VNC, il doit y avoir des logiciels qui font ça et qui sont encore maintenus aujourd’hui. Sans compter que pour les cas simples on peut faire du sshXforwarding.
@karchnu : à mon sens, cela apporte pourtant une réponse satisfaisante par le fait que l’utilisateur voit les manipulations opérées par la personne qui lui porte assistance — cf. les critiques de Tuxicoman à la solution qu’il propose dans son article —, ce que ne propose ni un accès SSH classique, ni par Xforwarding.
Par ailleurs, cela apporte un plus pédagogique que d’expliquer en direct une manipulation ou un mode de fonctionnement à une personne ; pas seulement de corriger un bug (je rappelle que le sujet de l’article est « Aide à une noob »).
Quant aux autres outils basés sur VNC, je n’en connais aucun qui propose une solution aussi simple et ergonomique à la connexion inversée.
Je la fait version un rien plus explicite (étant donné que même après les trois messages il n’y a aucun retour) : Ça serait fort agréable que l’article soit édité de manière à être ne plus être sexiste, merci d’avance ;)
Au lieu de VNC, quelqu’un a-t-il déjà essayé x2go ?
http://wiki.x2go.org/doku.php
Je ne comprend pas, il y a Alice et Bob et Alice est du genre féminin. Où est le problème? Que ce ne soit pas Bob qui soit dépanné par Alice?
@Tuxicoman
À titre personnel ce n’est pas tellement le fait que ce soit Alice qui se fasse aider qui me pose problème, mais plus le titre de l’article qui me dérange (les hommes aussi ont le droit d’être nuls en informatique et inversement les femmes ont aussi le droit d’être douées en info)
A une époque, il y avait une extension sur Empathy/Telepathy qui permettait de partager son terminal avec un utilisateur distant. Sans doute était-ce ssh-contact.
Ce que je vois c’est que la noob a quand même du boulot et doit savoir comment se servir d’un terminal. Elle ne doit pas être si noob que ça en fait… Ce qui en fait de facto, une femme douée en info. Plus de polémique.
Et sinon tmate.io