ssh sous windows

par Jean-Baptiste Marchand (19/11/2001)

Administration distante de systèmes Windows en ligne de commande Première partie : administration avec ssh (OpenSSH/Cygwin et PuTTY)

Introduction

Cette brève (en deux parties) présente deux techniques pour l’administration distante de systèmes Windows utilisant des interfaces en ligne de commande. Elle n’aborde pas les techniques d’administration donnant accès à l’interface graphique de Windows telles que VNC ou Terminal Server.

Les deux techniques présentées diffèrent par la méthode utilisée :

– la connexion à distance via une session ssh est, en quelque sorte, une méthode d’administration locale. Une fois l’administrateur connecté sur la machine, il utilise les outils fonctionnant en local sur la machine. Ceci est l’objet de cette première partie. – l’utilisation des Appels de Procédures à Distance (RPC, Remote Procedure Call en anglais) d’administration de Windows est une vraie méthode d’administration distante qui n’utilise pas les outils locaux de la machine à administrer. Ceci sera l’objet de la seconde partie.

Note : Le terme ‘système Windows’ désigne les systèmes d’exploitation Microsoft récents issus de la famille NT (New Technology) : Windows NT 4.0, Windows 2000 et Windows XP/.NET server.

Administration via SSH

SSH (Secure SHell) est un logiciel de type client-serveur permettant l’administration sécurisée d’un système distant via une interface en ligne de commande. Ce logiciel est devenu un standard de fait pour l’administration des systèmes de type Unix (la version 2 du protocole ssh est en cours de normalisation à l’IETF).

Le principal avantage de ssh comparé à un outil tel que telnet est l’utilisation de mécanismes cryptographiques afin d’assurer la sécurité d’une session distante. ssh permet ainsi de réaliser de l’authentification (serveur vis à vis du client, utilisateur vis à vis du système) et d’assurer la confidentialité de la communication, en utilisant des algorithmes de chiffrements symétriques éprouvés.

Conçu à l’origine pour les systèmes Unix, ssh est aussi disponible sur les systèmes Windows. Différentes mises en oeuvre de ssh sont disponibles, aussi bien côté client que côté serveur, qu’elles soient propriétaires ou libres (voir http://www.freessh.org/windows.html et http://www.openssh.com/windows.html pour une liste complète des logiciels existants).

Nous nous intéressons ici à la seule mise en oeuvre libre de serveur ssh disponible sous Windows : il s’agit du démon sshd du projet OpenSSH (http://www.openssh.com/ , mise en oeuvre de ssh en logiciel libre de loin la plus évoluée et active) fonctionnant avec la couche de compatibilité Unix écrite par Cygnus, Cygwin (http://www.cygwin.com/ ).

Côté client, PuTTY (http://www.chiark.greenend.org.uk/ sgtatham/putty/ ) est le client libre le plus fonctionnel et avancé. Il dispose notamment d’un émulateur de terminal bien fait, ce qui l’avantage par rapport à l’utilisation du client OpenSSH avec Cygwin, qui fonctionne dans le terminal texte particulièrement peu évolué de Windows.

Installation du serveur SSH

Pour l’installation du serveur SSH, il y a une alternative avec deux possibilités : – installer OpenSSH dans le cadre d’un environnement Cygwin – installer OpenSSH dans le cadre d’un environnement Windows

OpenSSH en environnement Cygwin

Pour comprendre cette première possibilité, rappelons que Cygwin est un projet lancé initialement par Cygnus (aujourd’hui RedHat), avec le but de fournir une couche de compatibilité Unix sur les systèmes Windows, afin de faire fonctionner , après une simple recompilation, des programmes écrits pour Unix.

Cette couche de compatibilité permet aujourd’hui de faire tourner de nombreuses applications, dont les nombreux utilitaires shell standards tels que awk, cut, grep, sed ou différents shells comme bash ou zsh.

En pratique, Cygwin se compose d’une DLL (cygwin1.dll), dans laquelle se trouve la couche de compatibilité Unix et d’une arborescence dans un sous-répertoire de la machine Windows, recréant l’arborescence classique d’une machine Linux (/bin, /etc/, /usr, /lib, …).

L’environnement Cygwin dispose d’un programme d’installation permettant de choisir les packages à installer. Ces packages sont classés par catégorie. Pour une installation d’OpenSSH, les packages des catégories suivantes doivent être installés : – Admin : cygrunsrv – Base : tous les packages – Interpreters : gawk

A la fin du programme d’installation, les programmes mkpasswd et mkgroup sont lancés, afin de créer les fichiers /etc/passwd et /etc/group, à partir des comptes du système Windows. Tout compte souhaitant être utilisé pour une connexion ssh doit apparaître dans le fichier /etc/passwd ; le fichier doit donc être récrée avec mkpasswd si un compte est ajouté.

Une fois l’installation de Cygwin terminée, la configuration du serveur se fait dans un shell Cygwin avec la commande ssh-host-config. Ce programme génère les clés du serveur et installe le démon comme service Win32, sous le nom de sshd, via le programme cygrunsrv. Le service est configuré par défaut pour se lancer au démarrage. Cependant, le lancement au démarrage échoue souvent, ce qui oblige à lancer le service à la main, par exemple avec la commmande ‘net start sshd’.

Cygwin recréant un environnement Unix, chaque utilisateur dispose d’un répertoire personnel sous /home. Les unités de disque Windows sont accessibles sous le répertoire virtuel (C : est par exemple sous /cygdrive/c). Une façon simple d’y accéder est de créer un lien symbolique pour chaque unité de disque du système, par exemple /c pointant vers /cygdrive/c.

Par défaut, le shell utilisé est bash, ce qui permet de retrouver un environnement de travail familier pour des administrateurs Unix. La plupart des utilitaires shell fonctionnant avec Cygwin sont disponibles, en plus des commandes standards de Windows. Cette méthode d’installation convient donc le mieux à des administrateurs Unix.

OpenSSH en environnement Windows

L’autre possibilité d’installation d’OpenSSH est de n’installer de l’environnement Cygwin que le strict nécéssaire et de travailler dans un environnement Windows classique, avec l’interpréteur de commandes cmd de Windows.

Cette configuration est plus simple à installer puisqu’elle est disponible sous la forme d’un programme d’installation autonome. Ce programme est disponible à l’adresse http://www.networksimplicity.com/openssh/ . A la fin de l’installation, le programme propose d’éditer le fichier /etc/passwd : il suffit de renseigner la liste des utilisateurs pouvant se connecter en ssh.

Par défaut, le shell lancé est cmd.exe, lancé via le programme switch.exe. L’utilisateur retrouve donc l’environnement Windows familier, identique à celui qu’il pourrait trouver en lançant une fenêtre de commande en mode interactif.

Installation du client SSH

PuTTY est le client SSH libre le plus avancé sous Windows. Il est développé activement et est très complet, avec notamment le support du protocole SSHv2. De plus, le manuel (en anglais), bien qu’encore incomplet, en fait un logiciel bien documenté.

L’installation de PuTTY est très simple et consiste en un seul executable (putty-x86.exe) à télécharger. Il est préférable d’utiliser les versions de développement, qui sont stables en pratique et ont des fonctionnalités supplémentaires intéressantes.

PuTTY offre quelques possibilités intéressantes telles que : – enregistrement de sessions (adresse du serveur, protocole, login, commande à exécuter à la connexion…) – configuration fine des options du terminal texte (caractères de contrôle, sonnette…) – gestion des connexions telnet, rlogin et mode brut – établissement de tunnels (redirection de ports et X11)

Cette dernière possibilité est très intéressante car elle permet d’établir des tunnels SSH, afin de sécuriser des protocoles transitant en clair sur le réseau.

Exemple : vous souhaitez administrer un serveur distant avec VNC, sur lequel vous pouvez installer un serveur ssh. Pour chiffrer le contenu de la session VNC, vous pouvez utiliser un tunnel ssh entre votre station d’administration et le serveur VNC. Sur votre station, vous connectez votre client VNC à un port local, qui est redirigé, via le tunnel ssh, vers le port VNC (5900) du serveur distant.

Une fois la redirection de port lancée, toute connexion établie vers le port 5900 de la machine locale est redirigée, via le tunnel ssh, vers le port 5900 du serveur VNC distant.

Pour réaliser cette configuration avec PuTTY, il faut : – aller dans l’onglet Connection/SSH/Tunnels – ajouter le numéro du port local redirigé (5900 ici) dans la case ‘Source Port’, en s’assurant que la marque ‘Local’ est activée. – indiquer la destination, c’est à dire la machine distante (serveur VNC) et le numéro de port (5900 pour VNC) – ajouter ce tunnel en cliquant sur ‘Add’.

Il suffit alors de se connecter de façon interactive vers le serveur SSH ; le tunnel sera établi à partir de cet instant.

Note : s’il n’est pas possible d’installer un serveur ssh sur le serveur VNC lui-même, il est possible d’utiliser une autre machine comme terminaison du tunnel SSH. Cependant, le trafic entre le serveur SSH et le serveur VNC transitera en clair. Cette possibilité n’est donc envisageable que si les deux serveurs sont sur un même réseau protégé.

Authentification par clés

En plus de l’authentification traditionnelle par login/mot de passe, ssh peut authentifier l’utilisateur grâce à des algorithmes de cryptographie à clés publiques (RSA, DSA). L’utilisateur place sa clé publique sur les serveurs ssh sur lesquels il souhaite se connecter et garde sa clé privée sur sa station de travail. Lors d’une connexion vers un serveur, le client ssh utilise la clé privée du poste local pour prouver au serveur l’identité de l’utilisateur.

Avant de pouvoir utiliser cette méthode, il faut commencer par créer un couple de clés : une clé privée et sa clé publique correspondante. Le programme PuTTYgen sert à cela. PuTTYgen peut générer des clés RSA (SSHv1 et SSHv2) et DSA (SSHv2) (DSA étant déconseillé par les développeurs de PuTTY), il faut donc choisir parmi ces 3 types avant de lancer la génération des clés. Afin d’accumuler une quantité suffisante d’aléa, il faut déplacer la souris de façon désordonnée lorsque le programme le demande.

Une fois le couple généré, il est conseillé de protéger la clé privée par une passe-phrase. Cette passe-phrase sert de clé symétrique pour chiffrer la clé privée et est demandée à chaque connexion. Si aucune passe-phrase n’est spécifiée, l’authentification se fera sans intervention de l’utilisateur _mais_ si la clé privée est compromise, il sera possible à un attaquant de se connecter sur tous les serveurs SSH contenant la clé publique de l’utilisateur.

La clé publique est à placer dans le répertoire .ssh/ du répertoire racine de l’utilisateur sur les serveurs SSH, sous le nom authorized_keys (l’utilisation du fichier authorized_keys2 pour les clés utilisées par SSHv2 est désormais obsolète depuis la version 2.9.9 d’OpenSSH). La clé privée est à stocker sur la machine locale, dans un fichier lisible uniquement par l’utilisateur et dont l’emplacement est à spécifier dans PuTTY, sous l’onglet de configuration Connection/SSH/Auth, pour chaque session définie dans PuTTY.

Dernier point, si vous disposez de plusieurs couples de clés que vous utilisez régulièrement et dont les clés privées sont protégées par une passe-phrase, il est pratique d’utiliser le programme Pageant, qui permet de charger une fois pour toute des clés privées, en ne saisissant qu’une seule fois la passe-phrase pour chaque clé. Par la suite, PuTTY interroge Pageant pour savoir s’il dispose d’une clé permettant de réaliser l’authentification. Ce programme est l’équivalent de l’outil ssh-agent d’OpenSSH.

Note : les clés privées générées par PuTTYgen autres qu’au format RSA1 (RSA SSHv1) ne sont lisibles que par le client PuTTY. Si vous vous connectez avec le client OpenSSH, préférez le programme ssh-keygen pour générer vos couples de clés.

Mise en garde

Il est important de garder à l’esprit que l’utilisation de l’environnement Cygwin doit être restreint à des personnes de confiance (typiquement des administrateurs). En effet, l’environnement Cygwin utilise des zones de mémoire partagée pour stocker des informations sur les processus. Ces zones n’étant en aucun cas protégées, il est potentiellement possible qu’un programme malin puisse modifier le comportement d’un autre programme en exécution de cette façon.

Références

Cygwin : http://www.cygwin.com/ OpenSSH : http://www.openssh.com/ PuTTY : http://www.chiark.greenend.uk/ sgatatham/putty/

Pour toute remarque : Jean-Baptiste.Marchand Mise en page, actualisation : karlesnine