Product SiteDocumentation Site

9.2. Connexion à distance

Il est essentiel pour un administrateur de pouvoir se connecter à distance sur un ordinateur. Les serveurs, confinés dans leur propre salle, disposent en effet rarement d'un clavier et d'un écran connectés en permanence — mais sont reliés au réseau.

9.2.1. Connexion à distance sécurisée : SSH

Le protocole SSH (Secured Shell, ou shell sécurisé) a été conçu dans une optique de sécurité et de fiabilité. Les connexions ainsi mises en place sont sûres : le partenaire est authentifié et tous les échanges sont chiffrés.
SSH offre encore deux services de transfert de fichiers. scp est un utilitaire en ligne de commande qui s'emploie comme cp sauf que tout chemin sur une autre machine sera préfixé du nom de celle-ci suivi du caractère deux-points.
$ scp fichier machine:/tmp/
sftp est un programme interactif très similaire à ftp. Ainsi, une même session sftp peut transférer plusieurs fichiers et il est possible d'y manipuler les fichiers distants (supprimer, changer leur nom ou leurs droits, etc.).
Debian emploie OpenSSH, version libre de SSH maintenue par le projet OpenBSD (un système d'exploitation libre basé sur un noyau BSD et qui se focalise sur la sécurité) et fork du logiciel SSH originel développé par la société finlandaise SSH Communications Security Corp. Celle-ci, qui en avait débuté le développement sous la forme d'un logiciel libre, avait en effet décidé de le poursuivre sous une licence propriétaire. Le projet OpenBSD créa donc OpenSSH pour maintenir une version libre de SSH.
OpenSSH est séparé en deux paquets. La partie cliente est dans le paquet openssh-client, le serveur dans openssh-server. Le métapaquet ssh dépend des deux parties et facilite leur installation conjointe (apt install ssh).

9.2.1.1. Authentification par clé

Chaque fois que l'on se connecte par SSH, le serveur distant demande un mot de passe pour authentifier l'utilisateur. Cela peut être problématique si l'on souhaite automatiser une connexion ou si l'on emploie un outil qui requiert de fréquentes connexions par SSH. C'est pourquoi SSH propose un système d'authentification par clé.
L'utilisateur génère une biclé sur la machine cliente avec ssh-keygen -t rsa : la clé publique est stockée dans ~/.ssh/id_rsa.pub tandis que la clé privée correspondante est placée dans ~/.ssh/id_rsa. L'utilisateur emploie alors ssh-copy-id serveur pour ajouter sa clé publique dans le fichier ~/.ssh/authorized_keys du serveur. Si, lors de sa création, la clé privée n'a pas été protégée par une « phrase de passe » (passphrase) qui la protège, toutes les connexions au serveur fonctionneront désormais sans mot de passe. Sinon, il faudra à chaque fois déchiffrer la clé privée donc saisir la phrase de passe. Heureusement ssh-agent va nous permettre de garder en mémoire la (ou les) clé(s) privée(s) afin de ne pas devoir régulièrement ressaisir la phrase de protection. Pour cela, il suffit d'invoquer ssh-add (une fois par session de travail) à la condition que la session soit déjà associée à une instance fonctionnelle de ssh-agent. Debian l'active en standard dans les sessions graphiques, mais cela peut se désactiver en modifiant /etc/X11/Xsession.options. Pour une session en console, on peut le démarrer manuellement avec eval $(ssh-agent).

9.2.1.2. Utiliser des applications X11 à distance

Le protocole SSH permet de faire suivre (forward) les données graphiques (dites « X11 », du nom du système graphique le plus répandu sous Unix) : le serveur leur réserve alors un canal de données spécifique. Concrètement, une application graphique exécutée à distance peut s'afficher sur le serveur X.org de l'écran local et toute la session (manipulation comme affichage) sera sécurisée. Cette fonctionnalité donne à une application exécutée à distance de nombreuses possibilités d'interférer sur le système local, elle est donc préventivement désactivée par défaut ; on l'activera en précisant X11Forwarding yes dans le fichier de configuration /etc/ssh/sshd_config du serveur. L'utilisateur pourra ensuite en profiter en spécifiant l'option -X de ssh.

9.2.1.3. Créer des tunnels chiffrés avec le port forwarding

Ses options -R et -L permettent à ssh de créer des « tunnels chiffrés » entre deux machines, déportant de manière sécurisée un port TCP (voir l'encadré B.A.-BA TCP/UDP) local vers une machine distante ou vice versa.
ssh -L 8000:serveur:25 intermediaire lance un ssh qui établit une session vers intermediaire tout en écoutant le port 8000 local. Toute connexion établie sur ce port fera débuter par ssh une connexion de l'ordinateur intermediaire vers le port 25 de serveur, à laquelle ssh la reliera.
ssh -R 8000:serveur:25 intermediaire établit également une session SSH vers intermediaire, mais c'est sur cette machine que le processus ssh écoute le port 8000. Toute connexion établie sur ce port fera débuter par ssh une connexion depuis la machine locale vers le port 25 de serveur, à laquelle ssh la reliera.
Dans les deux cas, il s'agit de créer des connexions vers le port 25 de la machine serveur, qui passent au travers du tunnel SSH établi entre la machine locale et la machine intermediaire. Dans le premier cas, l'entrée du tunnel est le port 8000 local et les données transitent vers intermediaire avant de se diriger vers serveur sur le réseau « public ». Dans le second cas, l'entrée et la sortie du tunnel sont inversées : l'entrée est le port 8000 d'intermediaire, la sortie est locale et les données se dirigent ensuite vers serveur depuis la machine locale. En pratique, dans les cas d'usage les plus courants, le serveur est soit la machine locale, soit l'intermédiaire.
Déport d'un port local par SSH

Figure 9.3. Déport d'un port local par SSH

Déport d'un port distant par SSH

Figure 9.4. Déport d'un port distant par SSH

9.2.2. Accéder à distance à des bureaux graphiques

VNC (Virtual Network Computing, ou informatique en réseau virtuel) permet d'accéder à distance à des bureaux graphiques.
Cet outil sert principalement en assistance technique : l'administrateur peut constater les erreurs de l'utilisateur et lui montrer la bonne manipulation sans devoir se déplacer à ses côtés.
Il faut tout d'abord que l'utilisateur autorise le partage de sa session. Dans Jessie, l'environnement de bureau GNOME inclut cette option dans son panneau de configuration (contrairement aux versions précédentes où il était nécessaire d'installer vino). En ce qui concerne KDE, il faut exécuter krfb pour pouvoir partager le bureau actif via VNC. Pour les autres environnements bureautiques, la commande x11vnc (du paquet Debian éponyme) a le même effet ; on pourra la rendre disponible à l'utilisateur via une icône explicite.
Lorsque la session graphique est rendue disponible par VNC, l'administrateur doit s'y connecter à l'aide d'un client VNC. GNOME propose pour cela vinagre et remmina, et KDE inclut krdc (dans le menu KInternetKrdc Connexion à un bureau distant). Il existe aussi des clients VNC qui s'invoquent en ligne de commande, comme xvnc4viewer, du paquet Debian éponyme. Une fois connecté, il peut examiner ce qui se passe, voire intervenir et montrer à l'utilisateur comment procéder.
VNC sert aussi aux utilisateurs nomades, ou responsables d'entreprises, ayant des besoins ponctuels de connexion depuis chez eux, qui retrouvent ainsi à distance un bureau similaire à celui qu'ils ont au travail. La configuration d'un tel service est plus compliquée : il faut d'abord installer le paquet vnc4server, modifier la configuration du gestionnaire d'écran pour accepter les requêtes XDMCP Query (pour gdm3, cela peut se faire en ajoutant Enable=true dans la section « xdmcp » du fichier /etc/gdm3/daemon.conf) et enfin démarrer le serveur VNC via inetd pour qu'une session VNC soit démarrée dès qu'un utilisateur essaie de se connecter. On ajoutera par exemple cette ligne dans /etc/inetd.conf :
5950  stream  tcp  nowait  nobody.tty  /usr/bin/Xvnc Xvnc -inetd -query localhost -once -geometry 1024x768 -depth 16 securitytypes=none
Rediriger les connexions entrantes vers un gestionnaire d'écran résout le problème de l'authentification, puisque seuls les utilisateurs disposant de comptes locaux passeront le cap de la connexion via gdm3 (ou les équivalents kdm, xdm, etc.). Comme ce fonctionnement permet sans problème plusieurs connexions simultanées (à condition que le serveur soit suffisamment puissant), il peut même être utilisé pour offrir des bureaux complets à différents utilisateurs itinérants (voire à des postes bureautiques peu puissants, configurés en clients légers). Les utilisateurs doivent simplement se connecter au 51e écran du serveur (vncviewer serveur:50) parce que le port employé est le 5950.