I. Introduction▲
Que ce soit pour installer, configurer ou maintenir des solutions serveur distantes (Web, cloud, etc.), ou pour dépanner ou assister des utilisateurs (famille, amis), il nous arrive fréquemment de souhaiter prendre le contrôle d'une machine distante. Selon l'usage que nous en aurons, nous nous satisferons d'un accès en ligne de commande, ou bien nous aurons besoin d'un accès en mode graphique. Dans ce dernier cas, nous pourrons nous contenter d'un affichage déporté, ou bien avoir besoin de partager le bureau d'un utilisateur distant.
Le but de ce tutoriel est de vous apprendre à mettre en place diverses solutions de prise de contrôle à distance d'une machine sous Linux, aussi bien depuis des clients Windows que Linux, en en présentant les avantages et inconvénients, sans omettre les questions de sécurité qui surgissent dès lors que cette connexion distante se fait à travers Internet.
Dans la plupart des solutions proposées ici, si l'on souhaite un accès à travers Internet, il faudra, depuis une box Internet ou un routeur, ouvrir un port et le rediriger vers la machine serveur.
Ce tutoriel ne prétend pas à l'exhaustivité des solutions possibles, qui sont nombreuses. Ne sont pas abordées ici, par exemple, des solutions telles que LogMeIn d'Hamachi, basée sur les échanges peer-to-peer, Chrome Remote Desktop, utilisant le navigateur Internet Chrome, pour vous donner quelques autres pistes.
Les commandes servant d'exemples sont celles valables pour les distributions basées sur Debian et ses dérivées. Il vous appartiendra d'adapter en utilisant la commande d'installation de paquets propre aux distributions que vous utilisez sur le serveur et sur le client.
II. SSH▲
SSH est un protocole permettant d'accéder à une machine en ligne de commande uniquement. Le contrôle d'accès se fait par login et mot de passe par défaut, mais on peut le renforcer à l'aide d'une authentification par clés. Les échanges entre les machines sont cryptés.
II-A. Mise en œuvre▲
II-A-1. Côté serveur▲
L'installation du serveur se fait par l'installation du paquet openssh-server :
sudo apt-get install openssh-serverUne fois installé, le service est automatiquement démarré et le sera aux démarrages suivants.
En cas de besoin, le service :
- s'active par :
sudo service ssh start- s'arrête par :
sudo service ssh stop- se relance par :
sudo service ssh restartLe port d'écoute par défaut est le port 22. Pour renforcer la sécurité, on peut modifier ce port en intervenant sur le fichier /etc/ssh/sshd_config, après quoi il faudra relancer le serveur.
Un contrôle d'accès uniquement par mot de passe est insuffisamment sécurisé. Certes le mot de passe transite de façon cryptée, mais n'importe qui réussissant, d'une manière ou d'une autre, à découvrir ce mot de passe pourra se connecter au serveur depuis n'importe quel appareil. Il est donc recommandé de mettre en place une authentification par clés. Son principe est de s'assurer que la personne qui saisit le mot de passe est bien la personne qu'elle prétend être. Il s'agit, en quelque sorte, d'une vérification d'identité.
Une authentification par clés requiert trois éléments :
- une clé publique ;
- une clé privée ;
- une phrase "mot de passe".
La clé privée permet au client de générer, à la demande de connexion, une signature cryptée envoyée au serveur. La clé publique permettra au serveur de vérifier que cette signature est authentique. Une phrase "mot de passe" est demandée lorsque le client veut ouvrir la clé privée pour générer la signature. Elle permet d'éviter qu'une personne, ayant réussi à dérober la clé privée, puisse l'utiliser.
La génération des clés se fait sur la machine cliente. Si celle-ci est sous Linux, il faut saisir, dans un terminal :
ssh-keygen -b 4096Le nombre 4096 permet d'indiquer un niveau de cryptage des clés. Plus ce nombre est important, plus sûr est le cryptage, mais plus il faudra de temps à la machine pour créer les clés.
Pour la raison évoquée un peu plus haut, il est conseillé de ne pas laisser le champ vide lors de la demande de phrase "mot de passe".
Si la machine cliente est sous Windows, il faut faire appel à l'utilitaire PuTTYgen (téléchargeable depuis cette page) pour générer les clés.
Il faut ensuite copier sur le serveur la clé publique du client. Si l'on n'a pas d'accès physique au serveur, il est possible de le faire par SSH lors d'une première connexion avec contrôle uniquement par mot de passe. Pour cela, une fois la clé générée, on saisit la commande suivante dans un terminal du client connecté au serveur si l'on est sous Linux :
ssh-copy-id -i ~/.ssh/id_rsa.pub login@IP-distanteSi l'on est sous Windows, on peut se connecter en SSH avec l'utilitaire PuTTY ou KiTTY. Mais nous aurons davantage d'opérations à faire qu'avec un client sous Linux. Les voici.
Une fois connecté, on vérifie l'existence du répertoire ~/.ssh. S'il n'existe pas, on le crée avec les droits appropriés :
mkdir ~/.ssh
chmod 0700 ~/.sshDe même, si le fichier authorized_keys n'existe pas, on le crée en lui donnant les droits nécessaires :
touch ~/.ssh/authorized_keys
chmod 0644 ~/.ssh/authorized_keysLorsque l'on a généré la clé avec PuTTYgen, depuis le champ "Public key for pasting…" on la sélectionne et on la copie. Puis, dans PuTTY, on édite le fichier authorized_keys par :
sudo nano ~/.ssh/authorized_keysEn fin de fichier, en s'assurant que l'on a bien un saut de ligne après une éventuelle clé déjà saisie, on colle le contenu du presse-papier (qui doit normalement contenir la clé publique) et on appuie sur [Entrée] pour aller à la ligne suivante. Enfin on enregistre le fichier.
Que l'on soit sur un client Linux ou Windows, il faudra ensuite désactiver la possibilité de se connecter par mot de passe, car à défaut l'authentification par clé ne servirait à rien ! Il faut pour cela intervenir dans le fichier de configuration /etc/ssh/sshd_config du serveur de façon à avoir les lignes suivantes :
[...]
PasswordAuthentication no
[...]
UsePAM no
[...]et redémarrer le serveur par :
sudo ssh reloadLes clés peuvent être générées sur le serveur. Dans ce cas, pour un client Linux, il faudra copier la clé privée (extension .ppk) sur le poste client et, pour des raisons de sécurité, l'effacer du poste serveur. Le contenu de la clé publique doit être copié dans le fichier ~/.ssh/authorized_keys.
Pour un client Windows, le format de clé utilisé par PuTTY ou KiTTY est différent. Il vous faudra employer l'utilitaire PuTTyGen pour convertir votre fichier de clé privée. Pour cela :
- lancez PuTTYGen ;
- à partir du menu Conversions --> Import Key, ouvrez le fichier de clé privée ;
- cliquez sur le bouton [Save private key] ;
- donnez le nom que vous voulez à ce fichier, sachant que c'est ce fichier qui devra être déclaré comme clé dans les paramètres de PuTTY ou KiTTY.
Enfin, sur le routeur ou la box Internet de votre FAI, il vous faut rediriger le port choisi dans la configuration SSH vers l'IP de la machine serveur, protocole TCP.
Il est très déconseillé d'accéder à une session root en SSH, cela constituant un danger pour le système. Généralement la configuration par défaut d'OpenSSH n'autorise pas un accès root.
II-A-2. Côté client▲
Depuis Linux, on accède à sa machine distante depuis un terminal par la commande :
ssh login@IP-distante -p numéro-portLe mot de passe de session est demandé.
Si une authentification par clés a été installée, la connexion se fait par :
ssh login@IP-distante -p numéro-port -i /chemin/clé-privéeSi l'on veut se connecter sans avoir à indiquer le chemin de la clé privée et le numéro de port, il faut configurer le fichier ~/.ssh/ssh_config après l'avoir créé si nécessaire.
Depuis Windows, il faut un logiciel tel que PuTTY ou KiTTY. Dans le champ HostName on indique l'adresse IP distante, et dans le champ Port le n° de port choisi sur le serveur. PuTTY ouvre une console avec demande du mot de passe de session. On se retrouve alors comme sur un terminal Linux ouvert sur sa session.
Si une authentification par clés a été mise en place, on doit paramétrer PuTTY en indiquant, dans la section SSH --> Auth, le chemin d'accès à la clé privée que l'on aura enregistrée avec PuttyGen.
II-B. Avantages▲
Solution sécurisée de prise de contrôle en ligne de commande d'une machine distante si on met en place une authentification par clés. Les échanges sont cryptés.
Elle conviendra parfaitement pour intervenir sur une machine distante n'ayant pas d'interface graphique, comme un serveur Web, par exemple.
II-C. Inconvénients▲
Sans authentification par clés, la sécurité est insuffisante pour un accès par Internet. Cela pourra toutefois suffire dans un réseau local. L'accès n'est possible qu'en ligne de commande.
III. SSH-X▲
Basé sur le protocole SSH, SSH-X permet d'accéder à une machine en déportant l'affichage pour intervenir de manière graphique et pas seulement en ligne de commande. Les échanges entre les machines sont cryptés.
III-A. Mise en œuvre▲
III-A-1. Côté serveur▲
La mise en œuvre est absolument identique à celle décrite dans la partie précédente pour SSH puisque nous utilisons ce protocole.
III-A-2. Côté client▲
III-A-2-a. Client Linux▲
Depuis Linux, on se connecte au serveur par :
ssh -Y user@IP -i /chemin/clé-privéeet on saisit le nom de l'application graphique à lancer, par exemple :
xterm &Le & permet d'éviter que la console reste occupée pendant que l'application s'exécute.
Il est possible d'afficher l'environnement de bureau complet. Il nous faut lancer un autre serveur X dans lequel nous pourrons afficher l'environnement graphique distant. Pour cela nous ouvrons une nouvelle console en appuyant simultanément sur [ctrl] [Alt] [F1]. Dans cette console, nous nous connectons à notre session en saisissant notre login et mot de passe. Nous ouvrons une session X sur un nouveau dispositif d'affichage par :
xinit xterm -- :1Dans le terminal qui s'ouvre dans l'angle supérieur gauche de l'écran, nous nous connectons au serveur en SSH, comme vu précédemment. Une fois connecté, nous ouvrons une session graphique depuis le serveur en lançant la commande adaptée à son environnement de bureau :
- pour Gnome, il faut lancer :
gnome-session- pour KDE :
startxkde- pour XFCE :
startxfce4Nous voyons alors apparaître le bureau distant. Si nous voulons revenir à l'environnement de bureau du poste client, il faut basculer sur la précédente session graphique en appuyant simultanément sur les touches [ctrl] [Alt] [F7]. On peut à tout moment revenir à la session graphique distante en appuyant à nouveau sur [ctrl] [Alt] [F1].
III-A-2-b. Client Windows▲
Depuis un client Windows nous aurons besoin, outre PuTTy, d'un second logiciel en mesure d'afficher l'écran graphique. Nous utiliserons par exemple XMing (il existe d'autres solutions comme Cygwin, VcXsrv Windows X Server, MobaXterm), que l'on peut se procurer à https://sourceforge.net/projects/xming/files/.
Dans les options de PuTTy, il faut cocher la case "Enabled X11 forwarding" dans Connexion --> SSH --> X11.
Nous lançons d'abord Xming, puis PuTTy avec lequel nous nous connectons au serveur en SSH en ayant pris soin de cocher l'option précédente. Il nous suffit alors, comme pour Linux, de saisir le nom de l'application graphique à exécuter pour que celle-ci s'ouvre dans XMing.
Pour disposer de l'environnement de bureau complet, il faut lancer dans PuTTy, une fois connecté, la commande de lancement de l'environnement graphique adaptée à l'environnement de bureau du serveur, comme vu précédemment pour un client Linux.
III-B. Avantages▲
Ce sont les mêmes que pour SSH, avec l'avantage complémentaire de pouvoir lancer des applications graphiques. C'est une solution qui permet par ailleurs de mettre en place une structure LTSP (Linux Terminal Server Project) permettant de faire fonctionner des clients légers en utilisant les ressources d'un serveur plus puissant.
III-C. Inconvénients▲
Si les applications se lancent bien sur le serveur, l'affichage est toutefois déporté. Lorsqu'on lance une application graphique depuis le client, celle-ci ne s'affiche que sur le poste client, bien qu'elle s'exécute sur le serveur, mais de manière invisible. On ne pourra pas se servir de cette solution pour faire une démonstration d'opérations à effectuer, depuis un poste client, sur l'écran du poste serveur. L'affichage du bureau complet n'est pas très simple.
IV. VNC▲
Le protocole VNC permet de prendre le contrôle à distance d'une machine en mode graphique. L'affichage peut être ou non déporté.
IV-A. VNC seul▲
Les échanges entre les machines ne sont pas cryptés.
IV-A-1. Mise en œuvre▲
IV-A-1-a. Côté serveur▲
Il existe plusieurs logiciels serveur VNC pour Linux : x11VNC, tightVNC, RealVNC… Pour Ubuntu, un client-serveur est installé de base, Vino. Nous prendrons ici l'exemple de x11VNC qui ne déporte pas l'affichage: ce qui s'affiche sur le client et le serveur est strictement identique, ce qui est un avantage lorsque l'on désire faire une démonstration à distance.
Nous l'installons par :
sudo apt-get install x11vncNous générons un mot de passe d'accès par :
sudo x11vnc -storepasswd "mon_mot_de_passe" ~/.vnc_passwdLe service se lance par :
x11vnc -many -rfbauth ~/.vnc_passwdSi nous désirons démarrer automatiquement le service avec la session, nous créons un fichier .desktop dans ~/.config/autostart avec le contenu suivant :
[Desktop Entry]
Type=Application
Exec=x11vnc -many -rfbauth ~/.vnc_passwd
Hidden=false
NoDisplay=false
Name=x11vnc
Comment=Bureau à distance VNCNous pouvons également le lancer automatiquement avec le système plutôt qu'avec une session. Le service sera alors disponible pour n'importe quel utilisateur. On se référera à des tutoriels à ce sujet.
Nous devrons encore faire une redirection du port 5900 vers l'IP locale du serveur sur notre routeur ou box Internet.
IV-A-1-b. Côté client▲
Il faut installer un client VNC. Là aussi, il en existe de nombreux. Il suffit généralement d'y indiquer l'IP distante du serveur pour que le client lance automatiquement une session après demande du mot de passe.
IV-A-2. Avantages▲
Solution facile à mettre en place au niveau serveur et client. On trouve facilement des clients VNC pour tous les systèmes d'exploitation. Avec un affichage non déporté nous pouvons assister un utilisateur à distance.
IV-A-3. Inconvénients▲
Le système d'authentification par mot de passe n'est pas suffisamment sécurisé, ce qui est d'autant plus dangereux si le service est automatiquement lancé au démarrage du serveur : la machine est exposée en permanence à toute tentative d'intrusion. De plus toutes les informations transitent en clair, les échanges n'étant pas cryptés. C'est donc à proscrire pour un accès par Internet. Cela convient davantage à un réseau privé.
VNC envoie des données d'affichage en point par point, avec toutefois des fonctions d'optimisation permettant de n'envoyer que les parties modifiées, ce qui implique le transit de grandes quantités de données. Aussi ce protocole peut-il s'avérer très lent et inutilisable dans le cas d'une connexion à faible bande passante.
IV-B. VNC par tunnel sécurisé▲
VNC n'étant pas suffisamment sécurisé pour une prise de contrôle à distance à travers Internet, différentes solutions existent, permettant de faire transiter les données au sein d'un autre protocole qui, lui, crypte les données et assure une authentification plus sûre du client.
IV-B-1. SSVNC▲
SSL est un protocole sécurisé utilisé notamment pour la sécurisation des données Internet du protocole HTTP, avec lequel il est combiné pour former le protocole HTTPS. Il est également utilisé pour la sécurisation des liaisons SSH. Combiné à VNC, il constitue le protocole SSVNC.
IV-B-1-a. Mise en œuvre▲
Tous les logiciels serveur et clients VNC ne sont pas en mesure d'utiliser le protocole SSVNC.
IV-B-1-a-i. Côté serveur▲
Nous installons un serveur SSVNC tel que x11vnc, par exemple, présent dans les dépôts des principales distributions, ainsi que son client qui nous permettra de générer les divers certificats d'authentification :
sudo apt-get install x11vnc ssvncNous générons certificat et clés en lançant le SSL/SSH VNCviewer et en cliquant sur le bouton [Certs], puis [Create certificats] :
Vous pouvez remplir les différents champs du certificat autogéré comme vous l'entendez. Nous indiquons le chemin d'enregistrement des fichiers de clés. Nous cliquons enfin sur [Generate Cert].
Il nous faudra récupérer la clé publique du serveur pour la copier sur le poste client. Il s'agit du fichier que vous venez de générer portant l'extension .crt.
Sur le serveur on démarre le service par :
x11vnc -stunnel /chemin/clé-privée.pem -manySi vous souhaitez que ce service soit lancé au démarrage, il vous appartiendra de placer cette commande dans un script exécuté au démarrage du système si vous voulez qu'il soit disponible pour toutes les sessions, ou en démarrage de session si vous désirez ne permettre cet accès qu'à une session.
IV-B-1-a-ii. Côté client▲
Nous installons SSVNC à partir des dépôts pour un client Linux :
sudo apt-get install ssvncou en le téléchargeant depuis sourceforge pour un client Windows.
Nous le lançons :
Nous renseignons l'adresse IP distante du serveur (ou l'adresse IP locale pour un réseau local), nous cochons l'option "Use SSL", nous cliquons sur le bouton [Certs] et nous indiquons le chemin d'accès au fichier certificat que nous avons récupéré sur le serveur dans le champ "ServerCert". Après avoir cliqué sur [Done] dans cette seconde boîte de dialogue, il ne nous reste plus qu'à cliquer sur [Connect] pour établir la connexion.
Tous mes essais à partir de clients Windows 10 ont échoué. La connexion est acceptée, mais SSVNC plante avec le message d'erreur "socket error while reading". Le problème ne se produit pas avec une connexion non sécurisée.
IV-B-1-b. Avantages▲
Cette solution nous permet d'obtenir une prise de contrôle graphique à distance par VNC tout en disposant d'une liaison sécurisée pour un accès à travers Internet. Elle ne demande pas trop de connaissances techniques.
IV-B-1-c. Inconvénients▲
Si la solution fonctionne parfaitement avec un client Linux, elle ne semble pas fonctionner depuis un client Windows 10.
IV-B-2. VNC par tunnel SSH▲
Les échanges entre les machines sont cryptés. L'authentification peut se faire par login et mot de passe, ou par clés publique et privée.
IV-B-2-a. Mise en œuvre▲
IV-B-2-a-i. Côté serveur▲
Nous devons commencer par mettre en place un serveur SSH. Pour cela suivez la démarche indiquée dans le paragraphe consacré à SSH. Nous devons également mettre en place un serveur VNC en suivant la méthode décrite pour VNC seul, mais sans effectuer la redirection de port VNC sur notre routeur/box Internet, car tout transite par le port SSH.
IV-B-2-a-ii. Côté client▲
Avec un client Linux, nous nous connectons au serveur en SSH en créant un tunnel pour le port VNC :
- avec authentification par mot de passe :
ssh login@IP-distante -p numéro-port -L 5900:localhost:5900- avec authentification par clés :
ssh login@IP-distante -p numéro-port -i /chemin/clé-privée -L 5900:localhost:5900Puis nous lançons un client VNC de notre choix en indiquant, dans le champ « adresse » de la machine distante :
localhost
Voici un script, à adapter, permettant de lancer directement un client VNC par tunnel SSH (ce script suppose que le client VNC installé est vncviewer) :
#!/bin/bash
xterm -e "ssh login@ip-distante -i /chemin/cle-privee -p N°-port -L 5900:localhost:5900; /bin/bash" &
sleep 10
xterm -e "vncviewer localhost"
exit 0L'attente de 10 secondes (sleep 10) est justifiée par la nécessité de laisser le temps à l'utilisateur de saisir les informations de connexion SSH.
Avec un client Windows nous devons utiliser, comme pour SSH, le logiciel PuTTY ou KiTTY que nous paramétrerons de la façon suivante :
Section Session
--> Champ Hostname : IP distante
--> Champ port : N° de port SSH
Section Connection
--> SSH
--> TunnelsChamp
--> Source port : L5900
--> Champ Destination : localhost:5900
et cliquer sur [Add]
Section Connection
--> SSH
--> Auth
--> Champ Private key for authentification : entrer le chemin d'accès au fichier de clé privée.
Nous lançons ensuite la connexion avec PuTTY ou KiTTY, puis nous lançons un client VNC avec le champ d'adresse du serveur paramétré à localhost.
IV-B-2-b. Avantages▲
Cette solution combine à la fois les avantages de VNC et ceux de SSH, ce qui permet une connexion et une liaison sécurisées à travers les réseaux publics.
IV-B-2-c. Inconvénients▲
La mise en œuvre de la solution nécessite quelques compétences techniques que ce tutoriel espère vous aider à surmonter. Pour simplifier encore les choses, vous pouvez vous reporter à ce script (valable uniquement pour les distributions de la famille Debian) qui automatise les opérations en s'adaptant aux choix de l'utilisateur. En fin d'opération il vous propose une fiche expliquant de manière détaillée et précise les opérations à faire sur le routeur/box Internet et sur le poste client.
IV-B-3. VNC par VPN▲
Un VPN (Virtual private Network) permet de créer, à travers Internet, un réseau entre des PC, comme s'il s'agissait d'un réseau local, en cryptant les échanges. C'est le protocole utilisé par les entreprises et les banques pour assurer la mise en réseau de leurs machines sur des sites distants. Sa sécurité repose sur une infrastructure à clés publiques : serveur et clients doivent disposer d'une clé publique et d'une clé privée, et une authentification doit être établie par une autorité accordant ou non une certification et disposant elle aussi d'un jeu de clés. Le certificat contient la clé publique.
La mise en place d'un tunnel SSH, tel que vu dans le paragraphe précédent crée un réseau similaire à un VPN.
IV-B-3-a. Mise en œuvre▲
IV-B-3-a-i. Côté serveur▲
Plusieurs protocoles VPN existent. Nous choisissons d'installer le protocole OpenVPN, open source, ainsi qu'un outil de génération de clés et certificats, par :
sudo apt-get install openvpn easy-rsaComme nous allons effectuer des modifications sur le contenu du dossier /usr/share/easy-rsa, nous devons le déplacer pour que des fichiers ne risquent pas d'être écrasés lors d'une future mise à jour d'easy-rsa (à faire en root) :
cp -r /usr/share/easy-rsa /etc/openvpn/Nous nous plaçons dans le répertoire dans lequel seront insérés clés et certificats :
cd /etc/openvpn/easy-rsaNous devons effectuer les opérations en root :
sudo su
source ./vars # exécute le contenu de vars dans le shell actuel
./clean-all # initialise le répertoire des clés
./build-ca # exécute le script générant les clés et les certificatsLe script demandera diverses informations qui seront intégrées au certificat. Vous pouvez personnaliser ce dernier, ou utiliser les valeurs par défaut en appuyant sur [Entrée].
Nous définissons les paramètres pour le cryptage des échanges :
./build-dhPar défaut est utilisé un cryptage sur 2048 bits. Si vous désirez modifier cette valeur, il vous faudra, avant de lancer cette commande, modifier la valeur de la variable définissant ce niveau de cryptage, par :
export KEY_SIZE=4096Nous lançons le script, suivi du nom que nous voulons donner à nos clés et certificat pour le serveur :
./build-key-server serveurDiverses informations nous seront demandées. Nous pouvons, comme précédemment, personnaliser ou laisser les valeurs par défaut. Pour des raisons de sécurité il est préférable de ne pas laisser le champ Passphrase vide. Une phrase "mot de passe" est plus sécurisée qu'un mot de passe, même s'il comprend des caractères spéciaux.
La phase d'initialisation de la connexion sécurisée entre le serveur et le client est coûteuse en temps machine et en ressources. Le serveur est alors beaucoup plus vulnérable aux attaques par déni de service. Pour éviter ce risque, on met en place une première authentification rapide (Handshake), par clé prépartagée entre le client et le serveur :
openvpn --genkey --secret /etc/openvpn/easy-rsa/keys/ta.keyNous devons maintenant effectuer la configuration du serveur dans le fichier server.conf. OpenVPN nous propose un fichier type que nous pouvons récupérer et installer dans le dossier d'openvpn par :
gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz >/etc/openvpn/server.confNous l'éditons. Certaines lignes seront à commenter ou décommenter (suppression du caractère # ou ; en début de ligne), d'autres à modifier ou à ajouter :
../..
# Le port par défaut est le port 1194. Choisir un autre port
# est une sécurité supplémentaire.
port 1194
../..
# Dans les lignes qui suivent vous devez indiquer les chemins
# vers les différents certificats et clés
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/serveur.crt
key /etc/openvpn/easy-rsa/keys/serveur.key
../..
# Le chemin vers le fichier des paramètres de cryptage
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
../..
# Les routes permettant aux machines distantes
# de se connecter au réseau local
# Il faudra donc adapter aux IP de votre réseau local,
# généralement 192.168.0.0 ou 192.168.1.0
push "route 192.168.0.0 255.255.255.0"
../..
# Décommenter cette ligne permettra à la machine cliente
# de faire passer tout son trafic réseau par le VPN
push "redirect-gateway def1 bypass-dhcp"
# L'adresse de vos serveurs DNS (ceux donnés ici sont ceux d'OpenDNS)
# si vous souhaitez utiliser d'autres serveurs que ceux de votre passerelle
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
../..
# Le chemin vers la clé Handshake
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
../..
# Nous activons la compression des données
comp-lzo
../..
# Le nombre maximum de clients autorisés à se connecter simultanément
max-clients 10
../..Nous devons activer la redirection de ports de la NAT (translation d'adresses du réseau) du routeur. À cette fin nous éditons le fichier /etc/sysctl.conf en décommentant la ligne :
net.ipv4.ip_forward=1et nous faisons prendre en compte ces nouveaux paramètres par le noyau en saisissant la commande :
sysctl -pDe la même façon que nous avons généré des clés pour le serveur, nous générons des clés pour le ou les clients (certaines opérations ne sont pas à refaire) :
cd /etc/openvpn/easy-rsa
source ./vars
./build-key clientCette opération peut être faite en même temps que pour le serveur.
Il est possible de n'utiliser qu'une même clé que l'on emploiera pour les divers clients qui auront à se connecter. Mais si cela paraît a priori plus simple, il est plus intéressant de générer une clé différente pour chaque client. Ainsi, si la sécurité d'un client est compromise, il suffit de supprimer sa clé sur le serveur pour interdire son accès ce qui n'empêchera pas les autres clients de se connecter.
Nous devons récupérer les clés et certificat du client pour les copier sur notre machine cliente. Selon que vous avez ou non un accès physique à la machine serveur, vous pouvez récupérer les fichiers au moyen d'une clé USB, ou par le réseau.
Les fichiers à récupérer sont les suivants :
- ca.crt
- client.key
- client.crt
- ta.key
Voici un tableau qui vous permettra de vous y retrouver plus facilement au sein de ces clés et certificats
Tableau des clés openvpn
|
Nom |
Utilisée par: |
Description |
Secret |
|
ca.crt |
Serveur et tous les clients |
Certificat racine du serveur |
NON |
|
ca.key |
Serveur seulement |
Clef du certificat racine du serveur |
OUI |
|
dh1024.pem |
Serveur seulement |
Paramètres Diffie Hellman |
NON |
|
client1.crt |
Client1 seulement |
Certificat du client |
NON |
|
client1.key |
Client1 seulement |
Clef du certificat du client |
OUI |
|
server.crt |
Serveur seulement |
Certificat du serveur |
NON |
|
server.key |
Serveur seulement |
Clef du certificat du serveur |
OUI |
Sur le routeur ou la box Internet de notre FAI, nous devons rediriger le port choisi dans la configuration VPN vers l'IP du serveur, protocole UDP.
IV-B-3-a-ii. Côté client▲
Nous devons également installer openvpn :
sudo apt-get install openvpnNous créons un dossier pour y placer nos fichiers clés et certificats :
sudo mkdir /etc/openvpn/keysNous y plaçons nos trois fichiers récupérés sur le serveur.
Nous créons une copie du fichier de configuration proposé en exemple par openvpn :
sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/client.confet nous l'éditons pour décommenter, modifier ou ajouter les lignes suivantes :
../..
# L'adresse IP du serveur et le port VPN utilisé, qui doit être
# le même que dans le fichier de configuration du serveur
remote IP-serveur 1194
../..
# Les chemins d'accès aux clé et certificats
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client.crt
key /etc/openvpn/keys/client.key
../..
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 1
../..
# Nous activons la compression des données
comp-lzo
../..Nous lançons la connexion depuis un terminal par :
sudo openvpn /chemin/client.confSi tout se passe bien, le terminal affiche :
Initialization Sequence CompletedPour interrompre la connexion VPN, nous faisons un [Ctrl] + [C] dans ce terminal.
Nous téléchargeons le client openvpn depuis cette page et nous l'installons.
Windows et Linux n'utilisent pas le même format de fichier de configuration d'openvpn. Windows ne reconnaît que les fichiers .ovpn qui sont des fichiers texte dans lesquels se trouve la configuration ainsi que les clés et certificats. Il s'agit en fait d'un fichier .conf de Linux dans lequel clés et certificats sont intégrés grâce à des balises <ca>, <cert>, <key> et <tls-auth>.
Le script OpenVPN-install, évoqué un peu plus bas, génère automatiquement un fichier .ovpn au format Windows. À défaut, voici comment procéder pour obtenir un fichier valide pour Windows.
Récupérez un fichier modèle de configuration client.conf à cette adresse. Renommez-le client.ovpn. Configurez-le comme pour le client Linux, mais sans la partie donnant les chemins vers les fichiers clé et certificats.
Insérez en fin de fichier les balises et la commande suivante :
<ca>
</ca>
<cert>
</cert>
<key>
</key>
key-direction 1
<tls-auth>
</tls-auth>Ouvrez le fichier ca.crt, sélectionnez son contenu, copiez-le et insérez ce que vous avez copié entre les balises <ca> et </ca>.
Faites la même chose avec le fichier client.crt, mais entre les balises <cert> et</cert>. Insérez le contenu du fichier client.key entre les balises <key> et</key>. Enfin le contenu du fichier ta.key entre les balises <tls-auth> et </tls-auth>.
Une fois ce fichier créé, lancez OpenVPN. Cela insérera une icône dans la barre de notifications. Faites un clic droit sur cette icône, choisissez "Import file" dans le menu qui s'affiche, et sélectionnez le fichier client.ovpn dans la boîte de sélection de fichiers. Ceci aura pour effet de créer une entrée de menu "client.ovpn" lorsque l'on fait un clic droit sur l'icône d'OpenVPN. Sélectionnez cette nouvelle entrée ; un sous-menu s'affiche, cliquez sur "Connecter" pour ouvrir la connexion.
IV-B-3-b. Avantages▲
Cette solution cumule les avantages d'un VPN avec ceux de VNC. Elle permet une connexion et une liaison très sécurisées à travers les réseaux publics.
IV-B-3-c. Inconvénients▲
Encore plus que pour la mise en place d'un tunnel SSH, cette solution nécessite des compétences techniques. Heureusement on trouve des scripts permettant d'automatiser l'opération et de la rendre très simple, comme PiVPN pour le Raspberry Pi, OpenVPN-install ou son fork pour Debian, CentOS et Arch Linux. Pour une installation personnelle ne dépassant pas deux connexions simultanées, on peut aussi utiliser Openvpn Access Server qui permet d'installer et configurer simplement, à travers une interface Web, un réseau OpenVPN. Openvpn Access Server n'est pas totalement libre.
En complément on pourra se référer à ce tutoriel pour la mise en place détaillée d'un serveur VPN sur Raspberry Pi.
V. Guacamole▲
Guacamole est une passerelle Web permettant de prendre le contrôle à distance de machines, en ligne de commande ou de manière graphique. Guacamole accède aux machines serveurs à travers les protocoles SSH, SSHX, VNC ou RDP, et traduit en HTML5 les données reçues pour les envoyer au client. La prise de contrôle peut ainsi se faire à partir d'un navigateur Web sans nécessiter l'installation d'un logiciel client, et donc à partir de n'importe quel système d'exploitation.
On peut installer le service Guacamole directement sur le poste serveur si l'on ne souhaite accéder qu'à ce poste précis. La machine jouera à la fois le rôle de passerelle et de poste serveur dont on prend le contrôle en localhost.
La solution Guacamole est particulièrement intéressante si l'on veut accéder facilement aux diverses machines d'un réseau local. On installe le service sur une des machines qui servira de passerelle, et on accédera aux autres machines dont on veut prendre le contrôle à travers cette passerelle. Cette passerelle peut même être utilisée pour accéder à d'autres machines à travers Internet.
V-A. Mise en œuvre▲
V-A-1. Côté serveur▲
Guacamole est dans les dépôts des principales distributions. Pour les distributions basées sur Debian, il suffira de faire, en root :
apt-get update && sudo apt-get install guacamolePour les distributions n'en disposant pas dans leurs dépôts, il faudra l'installer à partir des sources que l'on trouvera sur la page de téléchargement du site officiel. Il vous faudra suivre la procédure d'installation indiquée.
Des paquets supplémentaires seront nécessaires :
apt-get install guacamole-tomcatSi vous procédez à une installation depuis les sources, et que le paquet guacamole-tomcat n'est pas disponible dans les sources, il vous faudra installer la version la plus récente de tomcat lors de l'installation (tomcat8 à l'heure où est rédigé ce tutoriel).
On peut tester le succès de l'opération en tentant de se connecter depuis le navigateur d'un autre poste du réseau en saisissant l'adresse
http://192.168.0.13:8080/guacamole
(l'IP locale est à changer selon votre configuration locale ; la machine sur laquelle ont été faits les tests avait l"adresse 192.168.0.13).
Si tout a été correctement installé, on aboutit à une page Web demandant login et mot de passe :
Si vous souhaitez utiliser d'autres protocoles que VNC, il vous faudra également installer les plugins de Guacamole correspondant à ces protocoles (libguac-client-ssh, libguac-client-rdp). Il vous faudra par ailleurs avoir installé un serveur pour chacun des protocoles utilisés (VNC, SSH, RDP).
Nous allons maintenant configurer les accès des utilisateurs aux postes dont on veut prendre le contrôle. Cela se fait dans le fichier /etc/guacamole/user-mapping.xml auquel on ne peut accéder qu'en root. Voici son contenu :
<user-mapping>
<!-- Example user configurations are given below. For more information,
see the user-mapping.xml section of the Guacamole configuration
documentation: http://guac-dev.org/Configuring%20Guacamole -->
<!-- Per-user authentication and config information -->
<!--
<authorize username="USERNAME" password="PASSWORD">
<protocol>vnc</protocol>
<param name="hostname">localhost</param>
<param name="port">5900</param>
<param name="password">VNCPASS</param>
</authorize>
-->
<!-- Another user, but using md5 to hash the password
(example below uses the md5 hash of "PASSWORD") -->
<!--
<authorize
username="USERNAME2"
password="319f4d26e3c536b5dd871bb2c52e3178"
encoding="md5">
<protocol>vnc</protocol>
<param name="hostname">localhost</param>
<param name="port">5901</param>
<param name="password">VNCPASS</param>
</authorize>
-->
</user-mapping>Nous l'éditons. Nous voyons dans ce fichier deux exemples d'utilisateurs, l'un avec un mot de passe en clair, l'autre avec un mot de passe crypté par MD5. À fin d'exemple, nous allons créer un utilisateur sans mot de passe crypté, avec un accès SSH et un accès VNC. Pour cela nous décommentons les lignes du 1er utilisateur, ajoutons des noms pour chacune des connexions, et modifions les différents champs selon nos besoins :
<user-mapping>
<!-- Example user configurations are given below. For more information,
see the user-mapping.xml section of the Guacamole configuration
documentation: http://guac-dev.org/Configuring%20Guacamole -->
<!-- Per-user authentication and config information -->
<authorize username="USERNAME" password="PASSWORD">
<connection name="Accès SSH">
<protocol>ssh</protocol>
<param name="hostname">localhost</param>
<param name="port">22</param>
<param name="password">mon mot de passe SSH</param>
</connection>
<connection name="Accès VNC">
<protocol>vnc</protocol>
<param name="hostname">localhost</param>
<param name="port">5900</param>
<param name="password">mont mot de passe VNC</param>
</connection>
</authorize>
<!-- Another user, but using md5 to hash the password
(example below uses the md5 hash of "PASSWORD") -->
<!--
<authorize
username="USERNAME2"
password="319f4d26e3c536b5dd871bb2c52e3178"
encoding="md5">
<protocol>vnc</protocol>
<param name="hostname">localhost</param>
<param name="port">5901</param>
<param name="password">VNCPASS</param>
</authorize>
-->
</user-mapping>V-A-2. Côté client▲
Sur le client, il suffit d'ouvrir son navigateur et d'indiquer, dans la barre d'adresse, l'IP de la passerelle et le n° de port Guacamole, suivis de /guacamole :
http://xxx.xxx.xxx.xxx:8080/guacamole.
On arrive alors sur la page interface de Guacamole à partir de laquelle il n'y a plus qu'à sélectionner le protocole et la machine à laquelle on veut se connecter.
V-B. Avantages▲
Les données entre le serveur Guacamole et les postes clients transitant en HTML5, on peut prendre le contrôle à distance depuis n'importe quelle machine sous n'importe quel système d'exploitation disposant d'un navigateur Web.
Les ports utilisés étant les classiques ports Internet, il est ainsi généralement possible de passer à travers pare-feu et proxy. Guacamole pourra être utilisé là où d'autres solutions ne sont pas possibles pour cette raison.
La solution est particulièrement intéressante si l'on a plusieurs machines dont on veut prendre le contrôle, car elle permet de centraliser les accès.
V-C. Inconvénients▲
Les données transitant entre la passerelle Guacamole et le client ne sont pas cryptées, sauf si le protocole utilisé crypte lui-même les données (SSH, par exemple). Pour des protocoles non cryptés tels que VNC, la solution est à réserver à un réseau local, car la sécurité n'est pas assurée à travers Internet. Il est possible de mettre en place une liaison sécurisée par SSL, mais cela demande de bonnes connaissances techniques.
Sur un Raspberry Pi 3 comme serveur, l'affichage sur le client est très lent et de mauvaise qualité, y compris en SSH.
VI. NX et X2Go▲
X2Go est un logiciel open source de prise de contrôle graphique de PC à distance utilisant le protocole NX. Les échanges sont cryptés par tunnel SSH et le protocole utilise la compression vidéo des données pour des performances optimisées. Il fonctionne sur les systèmes d'exploitation Linux, Mac et Windows.
X2Go se compose de deux modules, un module serveur et un module client.
VI-A. Mise en œuvre▲
VI-A-1. Côté serveur▲
Un serveur SSH doit être installé et opérationnel sur votre distribution, puisque X2Go va créer un tunnel par ce canal.
Le module serveur de X2Go n'est pas présent dans les dépôts officiels des distributions. Nous devons donc ajouter le dépôt correspondant à la distribution de notre serveur que nous trouverons en consultant cette page.
Lorsque le dépôt est ajouté, nous mettons à jour la liste des paquets et nous installons les paquets nécessaires :
sudo apt-get update
sudo apt-get install x2goserver x2goserver-xsessionVous devrez rediriger, depuis votre box/routeur, le port SSH que vous avez choisi vers l'adresse locale de votre machine serveur.
VI-A-2. Côté client▲
Nous devons installer le client X2Go. Sous Linux, il se trouve dans les dépôts des principales distributions. Pour Debian et ses dérivées, par exemple, il nous suffit de saisir, dans une console :
sudo apt-get install x2goclientPour Windows, nous pouvons le télécharger depuis le wiki officiel.
Nous ouvrons le client X2Go dont l'apparence est très sensiblement la même sous Linux ou Windows. Depuis le menu, nous sélectionnons Session --> Nouvelle session…
Nous obtenons la boîte de dialogue suivante que nous complétons :
L'onglet "Connexion" vous permettra d'adapter les performances d'X2Go au type de connexion dont vous disposez, l'onglet "Entrées/sorties" de paramétrer la résolution ainsi que les DPI de la police d'affichage.
X2Go permet d'ouvrir une nouvelle session en affichage déporté, ou bien de partager le bureau d'une session existante.
VI-B. Avantages▲
Cette solution est simple à mettre en place, et offre de meilleures performances que les autres solutions de prise de contrôle graphique grâce à la compression des données et une réduction des requêtes client-serveur. Du fait de l'utilisation d'un tunnel SSH, elle est sécurisée pour un accès à travers Internet.
VI-C. Inconvénients▲
X2Go fonctionne parfaitement en affichage déporté en ouvrant une nouvelle session, mais le partage de bureau local connaît des difficultés avec un client Windows. Avec un client Linux, la connexion à un bureau local fonctionne, mais l'affichage est dégradé.
Avec un affichage déporté il ne sera pas possible d'assister un utilisateur sur le PC distant.
VII. Solutions propriétaires▲
Il existe des solutions grand public et très faciles à mettre en œuvre, mais propriétaires. Elles sont généralement gratuites pour un usage personnel.
VII-A. Teamviewer▲
Teamviewer est un service qui établit une passerelle entre un poste serveur et un poste client sans nécessiter de rediriger des ports sur des box/routeur. Teamviewer existe pour pratiquement tous les systèmes d'exploitation, y compris les appareils mobiles.
VII-A-1. Mise en œuvre▲
VII-A-1-a. Côté serveur▲
Depuis cette page vous devez télécharger la version de Teamviewer correspondant à votre distribution et l'installer manuellement.
Une fois lancé, l'interface vous indique un n° ID et un mot de passe à communiquer à la personne désirant prendre le contrôle de votre machine. Il vous est possible de mettre fin à la connexion à tout moment.
Si vous désirez pouvoir accéder à votre serveur sans avoir d'autorisation à donner à chaque connexion, vous devez paramétrer le logiciel afin qu'il démarre automatiquement avec le système. Il vous faudra créer un compte auprès de Teamviewer.
VII-A-1-b. Côté client▲
VII-A-1-b-i. Client Linux▲
Sur le poste client Linux, l'installation se fait de la même façon que pour le serveur, la même application permettant la connexion dans les deux sens.
Dans la fenêtre principale, dans la zone « Contrôler un ordinateur distant », vous renseignez le n° d'ID qui vous a été communiqué. Ensuite le mot de passe sera demandé, et une fenêtre s'ouvrira sur le système distant.
VII-A-1-b-ii. Client Windows▲
Le téléchargement se fait depuis cette page du site officiel. Lorsque vous lancez l'application, il vous est demandé si vous souhaitez l'installer ou simplement la démarrer.
Pour la prise de contrôle d'une machine distante, l'installation n'est pas nécessaire. Comme pour un client Linux, il suffit d'indiquer le n° d'ID et le mot de passe pour ouvrir une fenêtre sur le système distant.
Une version portable permet un accès bidirectionnel sans avoir à installer l'application. Ce peut être utile pour la lancer depuis une clé USB, par exemple.
VII-A-2. Anydesk▲
Anydesk propose une solution de prise de contrôle à distance, bidirectionnelle pour les systèmes Windows, Linux, MacOs et FreeBSD, et unidirectionnelle pour les systèmes Android et IOS. Comme pour Teamviewer, la solution permet de s'affranchir des redirections de port. Sous Windows le logiciel peut être utilisé en version portable, ou bien être installé.
VII-A-2-a. Mise en œuvre▲
La mise en œuvre est similaire à celle de Teamviewer. Avec Anydesk, il n'y a qu'une seule version du logiciel à utiliser sur la machine serveur ou cliente. C'est à partir de l'interface principale que l'on choisit soit d'être assisté (mode serveur) en communiquant le mot de passe indiqué, soit de prendre le contrôle d'un autre poste (mode client) en saisissant le mot de passe que l'on vous a communiqué. La machine serveur doit accepter la communication.
Il est possible d'autoriser un accès automatique à son poste de travail sans avoir à fournir un mot de passe à chaque fois et sans avoir à accepter la connexion. Il faudra pour cela créer un compte auprès de la société Anydesk.
VII-A-3. Avantages▲
Solutions très faciles à mettre en œuvre, qui ne demandent pas de grandes compétences techniques. Il suffit de savoir installer une application. Elles existent pour pratiquement tous les systèmes d'exploitation, ce qui permet de prendre le contrôle de n'importe quelle machine indépendamment du système d'exploitation. Le bureau est partagé, ce qui permet d'assister un utilisateur à distance. Les connexions sont sécurisées.
VII-A-4. Inconvénients▲
Ces solutions, même si elles sont gratuites pour un usage personnel, ne sont pas libres. Il faut faire confiance à des sociétés tierces, puisque ce sont elles qui ont le contrôle sur toutes les communications qui passent par leurs serveurs. Pour une prise de contrôle sans intervention d'un utilisateur sur le serveur, il faut créer un compte auprès de ces sociétés.
VIII. Remerciements▲
Je remercie chrtophe et Siguillaume pour leur relecture technique, gaby277 pour ses suggestions ; jacques_jean pour sa relecture orthographique.