Se libérer de Windows

Gazette Linux n°129 — Août 2006

Deny

Adaptation française

Joëlle Cornavin

Relecture de la version française

Article paru dans le n°129 de la Gazette Linux d'août 2006.

Article publié sous Open Publication License. La Linux Gazette n'est ni produite, ni sponsorisée, ni avalisée par notre hébergeur principal, SSC, Inc.


Table des matières

1. Première étape : installation du serveur OpenSSH
1.1. Configuration du serveur OpenSSH
1.2. Génération des clés de serveur
1.3. Démarrage du serveur OpenSSH
2. Un pied dehors — la ligne de commande Linux avec PuTTY
3. La liberté — une interface graphique Linux avec Xming
4. Ressources

Mon but est de montrer à un utilisateur de Windows comment ouvrir une session, utiliser aussi bien la ligne de commande que les applications graphiques sur un système Linux distant, Windows se chargeant de la présentation (et seulement de la présentation). Vous découvrirez comment installer OpenSSH sur un système Linux afin de fournir un accès sécurisé et faciliter l'interaction de l'interface graphique, comment configurer et employer un client SSH open source (PuTTY) et un serveur X open source (Xming) sous Windows. Avec ces outils, l'utilisateur de Windows peut en toute sécurité et facilement sortir d'un système Linux et travailler avec à distance comme s'il s'agissait du seul système sur lequel l'utilisateur se trouve.

1. Première étape : installation du serveur OpenSSH

Avant tout, il faut préparer un « espace sécurisé » sur un système Linux. Vous devrez installer un serveur OpenSSH sur un système Linux et le rendre accessible depuis le monde extérieur.

Comme la plupart des distributions Linux incluent (mettent à disposition) une version native d'OpenSSH, je n'entrerai pas dans les détails spécifiques à l'installation des paquetages natifs. À la place, je pars du principe que avez déjà trouvé et installé le paquetage approprié et que vous êtes prêt à le configurer.

1.1. Configuration du serveur OpenSSH

Le fichier de configuration par défaut du serveur OpenSSH se trouve dans /etc/ssh/sshd_config. Ce fichier texte contient trois types de texte : des lignes de blanc, des commentaires (qui commencent par un #) et des lignes de paires mot-clé/argument qui contrôlent le comportement du serveur SSH. Vous devez seulement vous préoccuper des lignes mot-clé/argument, puisque sshd ignore les commentaires et les lignes de blanc.

Bien que les valeurs par défaut des paramètres sshd (les valeurs supposées quand aucune option n'est indiquée) conviennent habituellement pour une utilisation normale de SSH, vous devriez définir explicitement les valeurs de quatre des paramètres pour un accès correct.

En particulier, définissez les options suivantes :

  • AllowTcpForwarding à yes

  • X11Forwarding à yes

  • X11DisplayOffset à 10

  • X11UseLocalHost à yes

AllowTcpForwarding

vérifie si le démon SSH autorisera ou non la retransmission TCP générique. Cette fonctionnalité permet aux clients SSH de diriger le trafic réseau choisi via le tunnel SSH pour qu'il se déplace en toute sécurité, du client jusqu'au serveur (ou vice versa). Bien que ce paramètre prenne par défaut la valeur yes, vous pouvez constater que le sshd_config lui donne explicitement la valeur no. Comme nous souhaitons garantir que la retransmission TCP est autorisée, vous devez la changer.

X11Forwarding

vérifie si le démon SSH prendra en charge explicitement ou non la retransmission SSH des flux de données X11. Ce paramètre prend par défaut la valeur no et vous devrez explicitement la définir à yes dans sshd_config afin de permettre à votre utilisateur Windows d'interagir facilement avec des applications graphiques Linux. Notez que, si l'option AllowTcpForwarding est activée, X11Forwarding est une commodité et n'est pas absolument nécessaire pour la tunnellisation X11.

X11DisplayOffset

spécifie le numéro DISPLAY initial pour les flux de données X11 transportés par SSH. Ce paramètre devrait être fixé à une valeur plus élevée que l'affichage X11 « réel » (localement rattaché) le plus élevé sur le système Linux, afin d'éviter d'interférer avec les utilisateurs locaux de l'interface graphique utilisateur. La valeur par défaut pour ce paramètre est 10, mais vous pouvez affecter une valeur supérieure si votre système Linux prend en charge un grand nombre d'utilisateurs de X.

X11UseLocalHost

contrôle si SSH peut « lier » la retransmission de X11 à l'adresse de bouclage local ou à l'adresse joker moins sécurisée. S'ils sont liés sur l'adresse de bouclage local, certains clients X11 plus anciens pourraient ne pas fonctionner correctement. La valeur par défaut pour ce paramètre est yes (la valeur que je souhaite vous voir utiliser explicitement), mais votre fichier de configuration initial peut avoir une valeur différente.

Des quatre paramètres ci-dessus, deux sont en général inutiles (puisque leurs valeurs par défaut sont de toute façon convenables) et il se peut que l'un des deux autres soit redondant. En particulier, X11DisplayOffset et X11UseLocalhost prennent par défaut des valeurs convenables, et vous n'avez pas à les modifier dans sshd_config. En outre, AllowTcpForwarding et X11Forwarding offrent aux clients des capacités similaires ; si AllowTcpForwarding est déjà spécifié, alors il est simple (mais non évident) pour un client d'effectuer une retransmission X11 sans l'option X11Forwarding. Si seule l'option X11Forwarding a été choisie, nos clients entrants peuvent retransmettre des sessions X11, mais aucun autre type de flux de données. Pour notre utilisateur Windows, vous devez autoriser l'accès à tous les flux de données du réseau (donc le réglage explicite d'AllowTcpForwarding) et lui permettre sans peine de retransmettre X11 en particuler (donc le réglage explicite d'X11Forwarding).

Une fois que vous avez effectué les changements appropriés dans votre fichier /etc/ssh/sshd_conf (voir fichier 1), enregistrez votre travail d'édition et poursuivez vers l'étape suivante : générer les clés de votre serveur SSH.

1.2. Génération des clés de serveur

Avant de pouvoir utiliser le serveur SSH, vous devez générer des clés de chiffrement pour celui-ci. Quelques distributions Linux se chargent, lors de la première exécution du serveur SSH, de créer ces clés, mais d'autres non. Lors de l'étape suivante, vous construirez explicitement trois ensembles de clés (un ensemble pour chaque méthode de conversation que comprend SSH) et les placerez dans les fichiers standard.

En tant que root, exécutez d'abord la commande ssh-keygen pour générer votre clé rsa1 dans le fichier /etc/ssh/ssh_host_key :


/usr/bin/ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ''

Ensuite, exécutez de nouveau la commande ssh-keygen , mais cette fois pour générer votre clé dsa dans le fichier /etc/ssh/ssh_host_dsa_key :


/usr/bin/ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''

Pour finir, lancez la commande ssh-keygen une troisième fois, cette fois pour créer votre clé rsa dans le fichier /etc/ssh/ssh_host_rsa_key :


/usr/bin/ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''

Avec ces commandes, vous avez donné à votre démon SSH à la fois des oreilles et une voix grâce auxquels votre utilisateur Windows peut communiquer avec l'environnement Linux.

1.3. Démarrage du serveur OpenSSH

En conclusion, il est temps de démarrer votre serveur OpenSSH, lequel emploiera la configuration et les fichiers de clés que vous avez préparés pour régler les conversations avec le monde extérieur. Si votre système lance le serveur SSH automatiquement, vous pouvez juste lui « signaler » qu'il doit relire sa configuration. Pour ce faire, en tant que root, exécutez :


/bin/kill SIGHUP `cat /var/run/sshd.pid`

pour envoyer le signal SIGHUP au démon SSH actuellement actif. Par ailleurs, si votre système n'a pas démarré le démon SSH, vous pouvez (à nouveau en tant que root) lancer le serveur sshd avec une commande simple :


/usr/bin/sshd

 

Dans la plupart des distributions, il est préférable de lancer les démons standard du système tels que SSH à l'aide des scripts situés dans /etc/init.d. Les deux tâches ci-dessus, par exemple, seront prises en charge avec /etc/init.d/ssh restart et /etc/init.d/ssh start exécutées en tant que root.

 
 -- Ben

À présent, vous avez complété la configuration supplémentaire de Linux, créé un accès verrouillé à votre « espace sécurisé » Linux (avez-vous pensé à régler votre pare-feu pour autoriser les connexions SSH ?) et franchi la première étape pour libérer cet utilisateur de Windows de son environnement. Naturellement, il aura encore besoin d'un compte sur le système Linux, que vous devrez créer avec les outils et méthodes standard de votre distribution. Au départ, il se connectera au système Linux en utilisant les nom d'utilisateur et mot de passe qui lui sont affectés ; par la suite, il aura le choix de se connecter via les fonctions sécurisées de SSH.

2. Un pied dehors — la ligne de commande Linux avec PuTTY

Les systèmes Windows complètement verrouillés, où vous ne pouvez même pas exécuter des programmes non approuvés depuis une disquette ou une « clé de mémoire » USB, sont les pires environnements. Vous ne pouvez rien faire sans la coopération de l'administrateur système Windows. Espérons que votre utilisateur Windows ne soit pas « prisonnier » d'un de ces environnements et ait au contraire un peu de latitude dans ses actions.

La première étape vers la liberté, côté Windows, consiste à installer l'application cliente SSH PuTTY. PuTTY est une application graphique Windows écrite et maintenue par Simon Tatham, et diffusée (à la fois sous forme d'exécutable et de code source) sous licence Open Source de type BSD. Une fois installé, il prend environ 2,8 Mo d'espace disque et crée un couple (non absolument nécessaire) d'éléments de base de registre Windows. Les six programmes de la suite PuTTY fournissent les outils clients nécessaires à notre utilisateur pour accéder à notre « espace sécurisé » Linux.

PUTTY.EXEIl s'agit du programme client SSH employé pour l'accès « en ligne de commande » aux systèmes extérieurs et c'est un substitut sécurisé pour la commande du client telnet.
PUTTYGEN.EXECe programme génère les « clés publiques » du client, à utiliser pour identifier le client sur le serveur SSH.
PAGEANT.EXECet outil est un « utilitaire de clé » (key agent) qui permet à l'utilisateur Windows de « mettre » de façon permanente les clés sélectionnées « à la disposition » des applications PuTTY. C'est une commodité (pour réduire le nombre de fois où un utilisateur doit saisir les informations de clé), non une obligation.
PSCP.EXEUn substitut à SSH pour la commande du client rcp, qui permet de copier en sécurité.
PSFTP.EXEUn substitut à SSH pour la commande du client ftp.
PLINK.EXECet outil est un programme client SSH (comme PUTTY.EXE) que l'on peut employer dans des processus automatisés (comme les fichiers .BAT et .CMD). D'autres programmes graphiques (comme Xming) utilisent également PLINK.EXE pour établir leurs propres connexions SSH vers les systèmes cibles.

Votre première tâche consistera à configurer PuTTY pour se connecter au système Linux. Ce sera une connexion simple qui dépend de l'identification de l'utilisateur Linux et de la confirmation du mot de passe ; on n'emploiera pas (encore) la puissance de l'autorisation par clé publique SSH pour vous donner un accès immédiat au système Linux. Nous garderons cette petite faveur pour plus tard.

Ainsi, depuis le menu DémarrerProgrammesPutty de Windows, vous pouvez à présent exécuter PuTTY. Le programme PUTTY.EXE démarre et vous présente une fenêtre de configuration PuTTY. Du fait que c'est votre première exécution de PuTTY et que vous n'avez encore défini aucune information de configuration, la fenêtre sera le plus souvent vide. Du côté gauche de la fenêtre, vous voyez une arborescence des options PuTTY et à droite, les paramètres concernant le menu Session. C'est ici que vous saisirez les informations de base nécessaires pour sortir de Windows et entrer dans votre ligne de commande Linux.

Dans le champ Host Name, saisissez le nom de DNS ou l'adresse IP de votre système Linux. Si vous avez l'intention de revenir à ce système (et vous le ferez probablement), vous pouvez enregistrer les informations de session en saisissant un nom significatif dans la zone de saisie Saved Sessions et en cliquant sur le bouton Save (figure 1, figure 2 et figure 3). À ce stade, vous pouvez lancer PuTTY et cliquer sur le bouton Load pour charger les informations de session du système Linux depuis la liste Saved Sessions, puis cliquer sur le bouton Open pour vous connecter immédiatement au système Linux.

Du fait que PuTTY n'a jamais conversé auparavant avec votre système Linux, il vous affiche la clé SSH fournie par le serveur OpenSSH de l'« espace sécurisé » (voir figure 4) et vous demande si vous lui faites confiance. Répondez Yes pour terminer l'établissement de la liaison SSH avec le système Linux ; si au contraire vous répondez No, alors PuTTY continue d'établir la liaison mais ne se rappellera pas que vous faites confiance au système Linux. Si vous répondez Cancel, PuTTY abandonnera totalement la connexion. Une fois que vous avez établie la liaison, il est maintenant très facile de compléter l'ouverture de session en mode texte avec vos nom d'utilisateur et mot de passe Linux (figure 5, figure 6 et figure 7). Vous avez terminé ; l'univers de votre système Linux vous attend, à partir d'une interface en mode texte (comme sur la figure 8).

3. La liberté — une interface graphique Linux avec Xming

Cependant, une interface en mode texte n'est qu'un « pis-aller » pour nos yeux accoutumés aux interfaces graphiques. Bien qu'il soit possible d'employer Linux de cette façon, vous préférerez probablement une interaction moins limitée, et cela suppose X. Votre utilisateur Windows appréciera mieux sa liberté si vous installez le serveur X Xming, ce qui sera votre prochaine étape.

Xming est une adaptation du serveur X11 de X.org pour l'environnement Windows, actuellement maintenu par Colin Harrison qui a succédé à Alexander Gottwald. La dernière version de Xming (lors de l'écriture de cet article) est basée sur le nouveau serveur X X11R6.9 de X.org et (comme PuTTY), elle est diffusée sous licence Open Source.

Contrairement à PuTTY, cependant, l'installation de Xming se déroule en plusieurs parties. Il existe deux serveurs X différents (un qui utilise OpenGL comme moteur de rendu et l'autre le moteur de rendu Mesa beaucoup plus lent) et un paquetage de polices de caractères. Vous devrez installer l'un des deux serveurs X et certaines des polices du paquetage de polices. Les installations sont très simples, se composant d'un assistant d'installation graphique bien connu, qui se charge de toutes les aspects pratiques de l'installation. La configuration (à ce stade) ne pos pas de problème ; les services Xming de base que l'installation met en place conviendront parfaitement à nos besoins. Dès lors que le serveur OpenGL et toutes les polices (obligatoires et optionnelles) sont installés, Xming prend environ 45 Mo d'espace disque (et quelques lignes de base de registre optionnelles) pour être installé.

Une fois que le serveur X et les polices sont installés, vous démarrez un serveur Xming « sans utilisateur root » en parcourant le menu DémarrerProgrammesXming de Windows et en cliquant sur l'option Xming. Le serveur X démarre et affiche une icône Xming (voir figure 9) dans votre barre d'outils. Xming n'est pas fourni avec les commandes xauth ou xhost (bien qu'elles soient disponibles par le biais d'un paquetage supplémentaire) et le serveur X n'autorise pas, par défaut, les applications distantes non authentifiées à se connecter et à utiliser l'affichage. Vous pourrez ajouter une partie des modules additionnels afin d'utiliser les outils X authority, mais à la place, je vais vous montrer comment employer les fonctions de retransmission X11 de votre serveur OpenSSH et amener votre client PuTTY à faire apparaître vos applications X11 distantes à titre d'applications locales vis-à-vis de Xming. Revenons donc à PuTTY.

Lorsque vous lancez PUTTY.EXE, vous voyez toujours en premier lieu une fenêtre de configuration. Lorsque vous vous êtes connecté la première fois à votre « espace sécurisé » Linux, vous avez (je l'espère) enregistré la configuration PuTTY pour cette connexion. À présent, vous voulez charger la session enregistrée en cliquant sur les boutons Load et Saved Session et la modifier un peu. Si vous faites défiler vers le bas la liste Category du côté gauche de la fenêtre de configuration, vous arrivez à un onglet intitulé X11. Sélectionnez cet onglet et modifiez ses paramètres (voir figure 10) pour activer la retransmission via le bouton Enable X11 Forwarding. Ensuite, faites défiler vers le bas jusqu'à l'onglet Sessions et enregistrez la définition modifiée en cliquant sur Save avant d'ouvrir la session avec Open sur votre système Linux.

Lorsque vous ouvrez la session, vous constatez que, du côté Linux de la connexion, la variable d'environnement $DISPLAY est à présent définie (voir figure 11) à un affichage sur le système Linux. Cet affichage n'existe pas réellement de façon physique ; il s'agit d'un des tunnels X11 que vous avez autorisés avec vos paramètres X11Forwarding et X11DisplayOffset de OpenSSH. Vos applications clientes X Linux pourront alors interagir avec OpenSSH au lieu d'un serveur X réel, et OpenSSH (sous Linux) relaiera les messages du protocole X vers PuTTY (sous Windows), lequel les transmettra alors sur votre serveur X Xming s'exécutant sous Windows. Le serveur X répondra inversement, en transmettant des données à votre client PuTTY, lequel les renvoie à OpenSSH pour qu'elles soient finalement prises en charge sur l'application X cliente. Il est certain qu'il s'agit d'un détour, mais il a plusieurs avantages :

  1. il fournit une couche de sécurité autour de votre trafic d'interface graphique ;

  2. il offre à vos applications X clientes une route assurée vers votre serveur X, garantissant qu'elles ne seront pas bloquées par des règles de pare-feu ou des problèmes de routage pouvant par inadvertance bloquer le trafic du protocole X ; et

  3. il élimine la nécessité d'employer les outils d'autorisation X (comme xauth ou xhost) car, pour votre serveur X, tout le trafic du protocole X est du trafic local.

Comme l'illustre la figure 12, à partir de cette configuration de PuTTY et de Xming, vous pouvez exécuter même l'application X la plus sophistiquée. Pour être franc, pratiquement n'importe quelle application X qui est à votre disposition sous Linux peut s'exécuter de cette manière. Seules ces applications qui requièrent des services non implémentés dans le serveur Xming (telles qu'OpenGL lorsque vous employez la version Mesa de Xming) ne peuvent tourner de cette façon.

J'ai maintenant atteint mon objectif et vous ai donné les outils pour libérer votre utilisateur de Windows. À présent, toutes les fonctionnalités de Linux s'offrent à lui, en ligne de commande comme avec des outils graphiques. Il n'a plus besoin de se confiner à son environnement de travail local et il peut travailler en toute liberté dans le système Linux distant.

4. Ressources

Canadien de naissance et habitant Brampton (Ontario), je suis technicien de carrière dans une grande banque. Depuis plus de 25 ans, je programme sur toutes sortes de systèmes, du Z80 CP/M au OS/390. Avant tout, je développe des applications MVS sur OS/390 pour les services bancaires, et j'ai incorporé Linux dans mon environnement de développement.

Adaptation française de la Gazette Linux

L'adaptation française de ce document a été réalisée dans le cadre du Projet de traduction de la Gazette Linux.

Vous pourrez lire d'autres articles traduits et en apprendre plus sur ce projet en visitant notre site : http://wiki.traduc.org/Gazette_Linux.

Si vous souhaitez apporter votre contribution, n'hésitez pas à nous rejoindre, nous serons heureux de vous accueillir.