 |
Autres langues français ; |
| Résumé : Cette page vous permettra de mettre en place votre propre système de contrôle à distance d’un autre ordinateur, à travers un tunnel chiffré. |
Contents
Pourquoi faire ?
Vous avez probablement entendu parler de logiciels comme Teamviewer ou Anydesk. Ils permettent de contrôler à distance un autre ordinateur pour, par exemple, porter assistance à un ou une amie venant juste d’installer Mageia, mais qui n’est pas encore à l’aise avec le monde Linux.
Cela permet aussi tout simplement de partager son écran lors d’un travail collaboratif ; pratique qui s’est fortement développée ces derniers temps !
Ces solutions sont gratuites pour une utilisation personnelle, mais elles font transiter les informations par des serveurs tiers. À terme, ces solutions pourraient aussi devenir payantes.
Il y a une autre option qui consiste à utiliser la fonctionnalité de connexion sécurisée à distance SSH (liens utiles), avec le protocole VNC (liens utiles) de partage d’écran et de prise de contrôle d’une machine distante.
VNC permet de sécuriser la prise de contrôle par un mot de passe, mais les informations circulent de manière non chiffrée à travers le réseau.
Avec SSH, nous allons créer un tunnel chiffré à travers lequel la communication se fera ; à l’instar d’un VPN, mais sans utiliser de serveur tiers. Selon votre débit de connexion internet, cette solution pourrait aussi être plus réactive.
Tous les paquets sont dans Mageia et ce tutoriel vous propose une méthode.
C’est facilement réalisable par tout utilisateur sachant exécuter des commandes et éditer un fichier dans une console, en tant que super-utilisateur.
2 méthodes d’ouverture du tunnel SSH
La question ici est de savoir qui établit le tunnel : l’utilisateur à assister depuis la machine distante ou la personne qui assiste depuis son poste.
Bien souvent, seulement une des 2 personnes sera capable de le faire, du fait que nos réseaux sont contrôlés par des routeurs (box internet par exemple) qui cachent les machines qui y sont connectées en un réseau local ; et en interdisent l’accès depuis l’extérieur.
Donc, il y a besoin d’avoir au moins une machine clairement visible de l’extérieur et autorisant les connexions entrantes. Cette machine sera appelée serveur SSH. Cela pourra être soit la machine à contrôler soit la machine qui prend le contrôle ; encore une fois, selon qui est accessible depuis l’extérieur.
Du côté éthique et respect de la vie privée, il est plus approprié que cela soit la personne qui à besoin d’assistance qui le demande et qui établit le tunnel. Sinon, en l’état, la prise de contrôle pourrait se faire à l’insu de l’utilisateur. A contrario, l’accès sera ouvert à la machine qui servira pour le support. Quelques pistes seront données à la fin du wiki afin de protéger cette machine.
De plus, bien souvent, il sera moins facile, voire impossible, de contrôler le réseau de la machine à contrôler.
Par exemple, la personne à assister à un ordinateur portable et se connecte à un réseau universitaire n’autorisant pas les connexions entrantes. On ne pourra pas contacter l’administrateur du réseau pour demander une exception. Ou cette personne ne sait pas comment agir sur sa box internet pour rendre sa machine visible depuis l’extérieur.
Par contre, la personne qui assiste, elle, contrôle en général son réseau personnel et sait le paramétrer. Elle pourra donc rendre visible sa machine plus facilement ; en utilisant la redirection de port sur sa box.
Le serveur VNC pour gérer la prise de contrôle devra, quant à lui, toujours être activé sur la machine à contrôler.
Voici deux schémas pour résumer tout cela.
- Figure 1
- Figure 2
Conventions importantes
- La machine distante est la machine sur laquelle vous souhaitez vous connecter à distance.
- Le client VNC est la machine depuis laquelle vous allez vous connecter à la machine distante.
- Le serveur SSH :
- Si vous choisissez l’option où c’est la machine distante qui ouvre le tunnel, alors le serveur SSH est sur la machine de la personne qui assiste, dite client VNC (figure 1).
- Si vous choisissez l’option où c’est la machine de la personne qui assiste, dite client VNC qui ouvre le tunnel, alors le serveur SSH est sur la machine distante (figure 2).
Installation SSH
L’installation de SSH pourrait faire l’objet d’une page wiki en soi ; juste l’essentiel est couvert ici. Plus d’informations se trouvent à Liens utiles
Installation initiale
| Attention ! Il faut avoir choisi la stratégie d’ouverture de tunnel pour être clair sur quelle machine est le serveur SSH. |
=> Sur la machine serveur SSH
Installer le paquet openssh-server par le CCM ou en ligne de commande, en super-utilisateur :
| # urpmi openssh-server |
puis lancer le service :
| # systemctl start sshd |
Pour finir ouvrir le port « serveur SSH » dans le pare-feu, à l’aide de l’interface dans le CCM.
À noter que par défaut, SSH utilise le port 22 et c’est celui-là que le pare-feu ouvre.
À ce stade, pour se connecter à distance sur votre serveur SSH sur le compte d’un utilisateur appelé, par exemple, assist, il suffit de taper la commande suivante :
| $ ssh -p 22 assist@ip_serveur_ssh |
Il vous sera alors seulement demandé le mot de passe du compte de l’utilisateur assist sur le serveur SSH et vous serez connecté.
-p 22 est optionnel, car le port 22 est le port par défaut. Si le serveur SSH utilise un autre port, cette valeur sera à ajuster (voir wiki SSH dans les Liens utiles).
L’adresse IP ip_serveur_ssh du serveur SSH sur le réseau local peut être trouvée, par exemple, par la commande ci-dessous ; en étant connecté physiquement sur cette machine, bien sûr.
| $ ip address show |
Restriction de la connexion par une clé d’authentification
Des personnes malveillantes pourraient essayer de se connecter à votre serveur SSH, en forçant le mot de passe ; pour un peu qu’il ne soit pas assez fort et que le nom de l’utilisateur soit facile à trouver.
Une façon de se protéger contre ce type d'attaque est de se forcer à se connecter uniquement avec une clé chiffrée, qui est beaucoup plus difficile à pirater.
Bien que recommandée, cette étape est facultative et vous pourriez décider de continuer à vous connecter au serveur SSH avec un identifiant et un mot de passe.
=> Sur l’autre machine que le serveur SSH
Se connecter avec l’utilisateur qui ouvrira le tunnel SSH (se remémorer votre stratégie).
Générer une clé chiffrée par la commande :
| $ ssh-keygen -t ecdsa -b 521 -C "votre@email" |
Comme ci-dessous :
- Utiliser le fichier par défaut /home/user_xy/.sshd/id_ecdsa pour stocker la clé.
- Entrer le mot de passe (passphrase) qui servira à déverrouiller la clé i.e. qui autorise l’utilisateur à utiliser cette clé. Taper « Entrée » pour ne pas spécifier de mot de passe.
La clé est maintenant créée dans le répertoire de l’utilisateur /home/user_xy/.ssh
Il reste à la faire connaitre au niveau du serveur.
Puisque nous venons d’installer SSH sur le serveur, nous pouvons encore nous en servir pour copier la clé vers le serveur SSH :
| $ ssh-copy-id -i /home/user_xy/.ssh/id_ecdsa assist@ip_serveur_ssh |
Il vous sera demandé le mot de passe de l’utilisateur assist sur le serveur (pour garder notre exemple).
| Remarque : Sans rentrer dans les détails, vous pouvez aussi créer cette clé sur une autre machine et envoyer la clé PRIVEE à la personne. Il faudra que la clé soit dans le fichier /home/user_xy/.ssh/id_ecdsa Côté serveur SSH, il faudra ajouter la clé PUBLIQUE /home/user_xy/.ssh/id_ecdsa.pub au fichier /home/assist/.ssh/authorized_keys (par exemple, cat id_ecda.pub >> /home/assist/.ssh/authorized_keys) |
| Attention ! Bien faire attention dans la note ci-dessus qu’il y a une clé PUBLIQUE et une clé PRIVEE. Intervertir les deux empêcherait le fonctionnement du serveur SSH, voire, pourrait le corrompre. |
=> Sur le serveur SSH
Il faut maintenant interdire la connexion avec le nom de l’utilisateur et son mot de passe, pour forcer l’utilisation de la clé d’authentification. Vous pouvez vous connecter avec le compte de l’utilisateur assist ou tout autre compte à partir du moment où vous pourrez basculer en tant que super-utilisateur.
En tant que super-utilisateur, créer le fichier /etc/ssh/sshd_config.d/sshd_restrict.conf et y ajouter le contenu suivant :
| ChallengeResponseAuthentication no PasswordAuthentication no AuthenticationMethods publickey PermitRootLogin no PermitRootLogin prohibit-password |
Redémarrer le service ssh par, en super-utilisateur :
| # systemctl restart sshd |
Voilà.
La connexion se fera maintenant à l’aide d’une clé d’authentification chiffrée uniquement. Il vous sera demandé un mot de passe qui est celui de la clé, et non plus celui de l’utilisateur (assist dans notre exemple).
Installation de VNC
=> Sur le serveur VNC (toujours la machine de la personne à assister, voir fig.1 ou fig.2)
- Installer x11vnc, par
CCMou en ligne de commande :
| # urpmi x11vnc |
- Créer un mot de passe pour x11vnc :
| $ x11vnc -storepasswd |
- Répondre oui ([y]) à la question :
| Write password to /home/user_xy/.vnc/passwd? [y]/n |
- user_xy est le nom d’utilisateur de la personne qui sera à assister (ou qui voudra partager son écran).
=> Sur le client VNC (toujours la machine de la personne qui assiste)
- Par
CCM, installer une visionneuse VNC (KRDCpour KDE ouremminapour Gnome, par exemple). - C’est le logiciel qui permettra de visualiser et de contrôler le serveur VNC depuis le client VNC.
VNC avec tunnel SSH
Ouverture du tunnel par l’assisté
Nous sommes dans le cas de la Figure 1. Ce que les anglo-saxons appellent Remote Port Forwarding, soit Redirection de Port à distance.
==> Sur la machine distante
La personne à assister, connectée à son compte user_xy (pour être cohérent avec l’exemple lors de la création du mot de passe pour X11VNC) va devoir lancer le serveur VNC et ouvrir le tunnel SSH.
Cela se fait en exécutant la commande :
| $ x11vnc -6 -auth guess -noxdamage -loop -repeat -rfbauth /home/user_xy/.vnc/passwd -rfbport 5901 -ssh assist@ip_serveur_SSH:3 |
Avec :
- assist le compte sur le serveur SSH, qui a reçu le certificat SSL.
- ip_serveur_SSH est l’adresse de la machine de la personne qui va assister et qui est le serveur SSH dans ce cas.
- -6 permet d’utiliser une adresse IPv6, si votre fournisseur internet la propose. Je ne détaillerai pas plus ici, mais les utilisateurs avancés feront le rapprochement.
- -rfbauth /home/user_xy/.vnc/passwd indique que la connexion VNC est protégée par un mot de passe (à ne pas confondre avec le mot de passe pour la connexion SSH -certificat SSL ou compte sur le serveur SSH).
- 5901 est le port que la machine distante utilisera pour envoyer de l’information et recevoir les commandes à distance.
- :3 indique que la machine utilisée pour assister (client VNC) devra utiliser le port 5903 (5900+3, 5900 étant le port par défaut pour VNC) pour communiquer.
Il va vous être demandé le mot de passe du certificat SSL pour le serveur SSH. Si vous n’avez pas implémenté cette fonction, cela sera un identifiant (assist dans notre exemple) et son mot de passe qui seront demandés.
Cette fenêtre devra rester ouverte tout le long du partage. Cette dans cette console que le serveur VNC s’exécute et autorise la connexion. Fermer cette fenêtre entrainerait une rupture immédiate de connexion.
Le tunnel SSH est maintenant créé et le serveur VNC est actif, prêt à partager l’écran et à donner le contrôle.
|
Ici sont des dragons ! Vous pouvez aussi créer une icône qui lance un script de connexion avec la commande x11vnc ci-dessus. Cela sera alors transparent pour la personne à assister. |
==> Sur le client VNC ou Serveur SSH
Il faudra vous assurer que votre box internet va rediriger le port SSH 22 vers la machine que vous utiliserez pour porter assistance et qui, dans ce cas, est à la fois le serveur SSH et le client VNC.
L’adresse ip_serveur_SSH de votre machine que vous aurez donnée à l’autre personne peut être trouvée, par exemple, en allant sur le site suivant, depuis cette même machine : DNS leak test
Si vous avez un nom de domaine pointant sur votre box, vous pouvez bien sûr l’utiliser.
Si vous êtes cantonnés dans votre réseau local, cela peut être l’adresse IP locale.
Pour vous connecter à la machine distante, ouvrir la visionneuse VNC (krdc ci-dessous) et demander à prendre son contrôle en entrant ses coordonnées localhost:5903
Une fenêtre s’ouvre pour configurer la connexion. Ne cochez pas Se connecter via un tunnel SSH car vous avez fait la connexion séparément. D’ailleurs, cela ne fonctionnerait pas par ce biais dans ce cas.
Il va maintenant être demandé le mot de passe de connexion à la session VNC. Rappelez-vous, c’est le mot de passe pour X11VNC qui a été créé par la personne à assister.
Et voilà, vous avez le contrôle !
Ouverture du tunnel par la personne qui assiste
Nous sommes dans le cas de la Figure 2. Ce que les anglo-saxons appellent Local Port Forwarding for VNC, soit Redirection Locale de Port.
Dans ce cas de figure, tout se passe depuis la machine de la personne qui assiste.
Par contre, auparavant, le serveur SSH a été installé sur la machine distante de l’assisté, le port SSH a été ouvert sur son pare-feu et son routeur redirige le trafic du port SSH 22 vers sa machine (chose pas forcément aisée pour la personne, voire impossible, comme expliqué précédemment).
Commande pour ouvrir le tunnel SSH et démarrer le serveur VNC :
| $ ssh user_xy@ip_machine_distante -L 5903:localhost:5901 "x11vnc -display :0 -noxdamage -loop -repeat" |
Comme précédemment, lancer alors la visionneuse VNC et la faire pointer sur localhost:5903
Éviter les intrus ou les embarras
Il faut garder en tête qu’une personne extérieure aura accès à la machine qui fait office de serveur SSH.
Cette personne peut se connecter à un compte sur votre machine à votre insu ou, inversement selon la stratégie choisie, vous pouvez vous connecter à la machine de l’assisté à son insu.
Quelques idées pour protéger la machine qui fait office de serveur SSH :
- N’activer le service sshd qu’au besoin.
- N’autoriser la connexion SSH dans le pare-feu qu'au besoin.
- Ne rediriger le port SSH 22 de votre box qu’au besoin.
- Créer un utilisateur spécifique (assist) qui n’a pas les privilèges root et qui est restreint dans un répertoire (mécanisme utilisant « chroot »). Vous pouvez d’ailleurs très bien ouvrir la visionneuse VNC à partir d’un autre compte que assist, à partir du moment où vous êtes connecté sur la même machine.
Si cela ne fonctionne pas
- Confirmer que vous avez bien identifié quelle machine fait office de serveur SSH.
- Vérifier, sur le serveur SSH :
- que le service sshd est bien actif.
- que le port SSH 22 est redirigé depuis votre box.
- que le pare-feu autorise la connexion SSH.
- Vérifier que l’ouverture du tunnel SSH se fasse en se connectant à l’utilisateur assist, pour qui la clé publique a bien été ajoutée à son compte.
- Vérifier que la personne à assister se connecte avec le compte user_xy qui a servi à créer la clé d’authentification.
- Poster sur le forum de Mageia :)
| Remarque : Certains réseaux wifis publics (« hotspots ») pourraient bloquer aussi les connexions sortantes, autres que celles liées à la navigation internet (port 80 et 443). La connexion SSH sur le port 22 (ou autre) est alors bloquée. Le multiplexing permet de contourner cela pour que SSH écoute aussi le port 443. Cela dépasse le cadre de ce wiki et cela pourrait être traité ultérieurement, si le besoin est exprimé. |
Liens utiles
