Forums d'entraide informatique - Astuces - Conseils

SSH : Secure Shell
A l'heure actuelle, la totalité des distributions GNU/Linux fournissent aussi bien le serveur que le client SSH. Du fait de cette grande diffusion, un certain nombre de documentations ont été écrites, aussi bien en français que dans toutes les autres langues. Il s'agit souvent, malheureusement, de papiers très théoriques, et l'utilisateur n'est guère avancé quant à
l'utilisation effective de SSH.
Notez que cet article est déjà paru dans Linux Magazine 33. Cependant, en tant qu'administrateur, il vous est indispensable de pouvoir vous connecter sur votre serveur de manière sécurisée. Le présent hors série n'aurait donc pas été complet sans décrire la manière d'utiliser OpenSSH par la pratique. Nous avons donc choisi de rééditer cet article, qui vous donnera toutes les indications nécessaires pour sécuriser vos connexions.
Nous allons, avec cet article, tenter d'aborder l'as- pect pratique de la mise en œuvre d'un serveur sshd ainsi que l'utilisation du client et des divers élé- ments de contrôle. Mais avant d'entrer dans le vif du sujet, passons tout de même par la case présen- tation, histoire de voir de quoi on parle.
SSH
SSH est un logiciel fournissant des fonctionnalités semblables à rlogin, rsh, rshd et rcp, mais dont les connexions entre les machines cliente(s) et serveur sont chiffrées. Le principal problème de ces équivalents historiques était de transmettre toutes les informations en clair sur le réseau (LAN ou Internet). Ceci ouvrait la porte à des attaques très importantes, puisqu'il suffisait à l'attaquant d'écou- ter le réseau avec un utilitaire adéquat (comme le simple tcpdump) pour non seulement assister en direct à tous les échanges entre clients et serveurs mais également. par la même occasion, voir tous les mots de passe transiter.
rlogin, rsh et rcp ne sont pas les seuls pro- grammes à procéder de la sorte ; la majorité des protocoles traditionnels échangent toute informa- tion en clair sur le réseau. C'est le cas de FIT. HTTP, POP3, IMAP, NFS et tant d'autres. De base, SSH permet de remplacer les utilitaires four- nissant une connectivité à distance pour le shell. Nous verrons plus loin dans cet article qu'il est par- faitement possible, grâce à SSH, de sécuriser des protocoles déjà existants.
Nous l'avons dit, SSH chiffre la communication pour éviter les écoutes passives. Mais SSH apporte d'autres fonctionnalités très intéressantes en termes
de sécurité. Il propose par exemple un système d'authentification des machines en présence. Normalement, une machine est identifiée par une adresse ou un nom. Malheureusement, ces informations peuvent facilement être utilisées par un attaquant pour faire croire que sa machine est l'une des deux autorisées (client ou serveur). SSH permet d'ajouter une couche d'authentification en identifiant les parties en présence à l'aide d'une clef. Ainsi, si usurper une adresse ou un nom de machine est quelque chose de relativement facile, obtenir une clef est presque impossible.
Concernant le logiciel lui-même. SSH est originelle- ment un logiciel propriétaire, certes libre d'utilisation dans un but non-commercial, mais cela n'est pas suffisant dans une optique qui est celle que nous défendons. Voilà pourquoi la quasi-totalité des utilisateurs préfèrent OpenSSH, qui est une implémentation Libre (licence BSD). OpenSSH repose entièrement sur une bibliothèque de fonctions nommée OpenSSL et utilisable sous les termes d'une licence de type Apache.
OpenSSL contient tous les éléments cryptographiques nécessaires au fonctionnement d'OpenSSH.
Protocoles
Le protocole SSH existe en deux versions majeures. SSHI, le premier (historiquement) se décline en deux sous-versions notées 1.3 et 1.5. L'autre version du protocole. SSH2, est plus récente et corrige également quelques erreurs de conception. Sans rentrer dans le détail, SSH I utilise un CRC (somme de contrôle) pour assurer l'intégrité des données trans- mises. Ce procédé étant trop faible. SSH2 l'a rem- placé par un autre algorithme nommé HMAC. Autre changement majeur, SS1-I1 était monolithique

alors que SSH2 divise le protocole en couches qui sont documentées dans des RFC différentes.
OpenSSH supporte aussi bien SSH1 (1.3 et 1.5) que SSH2 dans sa version la plus récente (OpenSSH 2.9.9).
Mise en oeuvre
Après cette brève introduction théorique, passons au côté pratique et commençons par installer les éléments nécessaires à OpenSSH dont la biblio- thèque OpenSSL. Bien que certaines distributions possèdent un système de packaging extrêmement performant (comme la Debian), il est plus efficace que compiler vous-même les éléments dont vous avez besoin. Il est très important d'utiliser les toutes dernières versions disponibles car des bogues et des failles de sécurité (importantes ou non) sont décou- verts régulièrement.
Vous pourrez récupérer les sources mais également des packages pour votre distribution sur le serveur officiel : wmm.openssl.com. Ici, nous considérerons une installation à partir des sources. Décompressez l'archive comme d'habitude avec :
5 tar xfzv openssh-2.9.9p2.tar.gz
Notez qu'une archive openssl-enaine- O . 9 . 6b. tar .gz est présente sur le serveur offi- ciel. Il s'agit d'un module supplémentaire permet- tant le support de certains périphériques cryptogra- phiques (CryptoSwift, Compaq Atalla et nCipher CHI pour le moment). Considérez ce module comme expérimental, bien que très stable. Ne pos- sédant pas un seul des périphériques en question, nous n'avons pas procédé à des tests. Peut-être en parlerons-nous en un futur article.
Pour configurer et compiler les sources, nous utili- sons le script fourni permettant de définir le type de plate-forme et le compilateur à utiliser
$ ./config $ make
$ su
$ make install
$ ldconfig $ exit
Dans le doute, assurons-nous que tout est correcte- ment installé et fonctionne
$ /usr/local/ssl/bin/openssl version OpenSSL 0.9.6b 9 Jul 2001
Ceci fait, nous pouvons passer à la compilation et installation d'OpenSSH
$ tar xfzv openssh-2.9.9p2.tar.gz $ cd openssh-2.9.9p2
Ici, un script de configuration automatique auto- conf /automake permet de paramétrer les sources. Parmi les options disponibles, on notera la possibilité d'utiliser un support PAM (que la docu- mentation donne comme étant plus efficace que dans la version commerciale de SSH). Si vous dési- rez activer le support PAM, il vous suffira d'ajouter
le paramètre --with-pam lors de l'exécution du
script . /configure. Cependant, les options par défaut devraient vous satisfaire :
$ ./configure
Au terme de l'exécution du script de configuration, vous verrez apparaître à l'écran un résumé de la configuration. Tout d'abord, vous serez renseigné sur l'emplacement des binaires et des différents élé- ments sur le système de fichiers
OpenSSH has been configured with the following options:
User binaries: /usr/local/bin
System binaries: /usr/local/sbin
Configuration files: /usr/local/etc
Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/manX
PID file: /var/run
sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin andom number collection: Device (/dev/urandom) Manpage format: doc
Ensuite viendront les différents supports dispo- nibles
PAM support: no
KerberosIV support: no
Smartcard support: no
AFS support: no
S/KEY support: no
TCP Wrappers support: no MUS password support: no
IP address in $D1SPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: yes

Enfin, vous pourrez voir les configurations relatives à la compilation proprement dite :
Host: i586-pc-linux-gnu
Compiler: gcc
Compiler flags: -g -02 -Wall -Wpointer-arith -Wno- uninitialized
Preprocessor flags: -I/usr/local/ssl/include Linker flags: -L/usr/local/ssl/lib
Libraries: -lz -1nsl -lutil -lcrypto -lcrypt
Vous pourrez obtenir la liste complète des para- mètres permettant de changer cette configuration à l'aide de l'option --help. Si vous êtes satisfait de ces éléments, vous n'aurez plus qu'à lancer la com- pilation avec :
$ make
$ su
$ make install
$ exit
Nous disposons à présent d'une installation fonc- tionnelle d'OpenSSH qui supporte aussi bien le pro- tocole SSH1 que le SSH2.
Vous trouvez dans le répertoire contrib des sources d'OpenSSH un certain nombre de sous- répertoires nommés avec des noms de distributions GNU/Linux. Il s'agit des scripts d'init permettant de démarrer, de stopper et de recharger le service OpenSSH automatiquement. En fonction de votre distribution, placez le script adéquat dans le réper- toire correspondant à votre distribution. Veillez à vérifier dans le script que les différents chemins cor- respondent effectivement à ceux où sont installés les binaires OpenSSH.
Les clefs
Pour OpenSSH, qui supporte en même temps les deux protocoles (SSH1 et SSH2), il est nécessaire de passer par l'étape de création des paires de clefs publique/privée. Au terme de la procédure make install, vous avez dû voir apparaître une ligne concernant la génération de clefs. Nous allons cependant reprendre cette étape à la main afin de bien comprendre les implications sous-jacentes.
Le protocole SSH1 utilise une paire de clefs de type rsal , alors que le protocole SSH2 permet au choix l'utilisation de paires de type dsa ou rsa (ne confon- dez pas rsa et rsal). Nous devons donc, dans un premier temps, générer une paire de clefs pour l'hô- te où nous venons d'installer OpenSSH. Pour cela,
nous utiliserons le bien nommée ssh-keygen
IMPORTANT : Les paires de clefs de l'hôte ne doi- vent avoir AUCUNE PHRASE DE PASSE! De plus, vous devrez préciser les chemins et les noms des fichiers à créer.
$ su
$ ssh-keygen
Generating public/private rsal key pair.
Enter file in which to save the key (/root/.ssh/identity): /etc/ssh_host_key
Enter passphrase (empty for no passphrase): Enter same passphrase again:
Your identification has been saved in /etc/ssh_host_key.
Your public key has been saved in /etc/ssh_host_key.pub.
The key fingerprint is: 15:16:40:57:ed:98:5a:a4:bf:d4:6a:lb:49:64:cc:5e root@morgane
Nous procédons de même en générant une paire de clefs dsa et rsa pour le protocole SSH2.
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/roothssh/id_dsa): /etc/ssh_host_dsa_key Enter passphrase (empty for no passphrase): Enter same passphrase again:
Your identification has been saved in /etc/ssh_host_dsa_key.
Your public key has been saved in /etc/ssh_host_dsa_key.pub.
The key fingerprint is: bc:de:e0:55:93:60:46:0c:38:4c:71:03:68:57:6e:le root@morgane
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/roothssh/id_rsa): /etc/ssh_host_rsa_key Enter passphrase (empty for no passphrase): Enter same passphrase again:
Your identification has been saved in /etc/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh_host_rsa_key.pub.
The key fingerprint is: 74:23:9e:a8:e8:26:a5:08:04:83:40:de:ab:a6:c6:85 root@morgane
Nous avons à présent toutes les clefs d'hôtes néces- saires au fonctionnement d'OpenSSH
$ ls /etc/ssh*

SSH : Secure Shell
/eccissh_host_dsa_key.pub /etc/ssh_host_key
/etc/ssh_host_key.pub /etc/ssh_host_rsa_key /etc/ssh_host_rsa_key.pub
Les clefs privées ne possèdent pas de suffixe et les clefs publiques possèdent un suffixe . pub. Vous reconnaîtrez aisément les différents types de clefs par le biais du nom de chaque fichier. Notre hôte est prêt pour l'exécution du serveur sshd que nous lançons avec le script d'init adéquat (en fonction de votre distribution).
Passons maintenant à l'utilisateur. Il conviendra à chaque utilisateur de générer ses paires de clefs de la même manière que nous venons de le faire. Seule différence, il ne sera pas nécessaire de préciser un emplacement spécifique puisque les valeurs par défaut feront l'affaire. Chaque utilisateur générera les trois types de clefs (rsal, dsa et rsa) afin de pouvoir communiquer avec n'importe quelle implémentation récente ou non de SSH.
Voici les fichiers qui seront créés dans le répertoire personnel de l'utilisateur :
.ssh/id_dsa
.ssh/id_dsa.pub .ssh/id_rsa
.ssh/id_rsa.pub .ssh/identity .ssh/iden-jty.pub
Quelques explications sont maintenant nécessaires pour bien comprendre ce que nous avons fait. Chaque utilisateur possède une paire de clefs (peu importe leur type). Pour se connecter à un serveur sshd, il peut choisir deux façons de le faire : soit utiliser ses clefs, soit utiliser son mot de passe puisqu'il possède un compte sur la machine distante. Nous verrons plus loin les différentes manières de vous authentifier auprès du serveur et comment configurer ce dernier.
Fichiers de configuration
Il existe deux fichiers de configuration distincts, ssh_conf ig pour le client et sshd_conf ig pour le serveur. Chacun de ces fichiers peut être personnalisé par l'ajout ou la suppression de lignes de configuration. Le fichier de configuration du serveur doit être placé à l'endroit spécifié dans le résumé de la configuration donné à la suite du
.    /configure des sources. Ce fichier est commun
à toute la machine et ne devra être modifié que par l'administrateur.
Le fichier de configuration du client SSH, en revanche, peut être placé dans le même répertoire, mais l'utilisateur pourra glisser dans le . ssh de son répertoire personnel un fichier config qui écrasera les valeurs du fichier global.
Des exemples des deux fichiers de configuration sont livrés avec les sources d'OpenSSH. Il vous suffira de les placer dans le répertoire adéquat et de les éditer pour vous en servir comme base de travail.
Dans un premier temps, attachons-nous au fichier de configuration du serveur :
•    La première chose à faire est de renseigner le serveur sur le port à utiliser et les protocoles SSH que nous souhaitons supporter :
Port 22 Protocol 2,1
Nous pourrions par exemple ne supporter qu'un seul protocole afin de simplifier la gestion des clients et des connexions. Un autre paramètre intéressant est :
ListenAddress <IP>
Celui-ci permet. dans le cas d'une machine possédant plusieurs interfaces réseau, de n'écouter que les connexions entrantes par l'interface possédant cette adresse IP
•    Nous définissons ensuite les fichiers où se trouvent les différentes clefs de l'hôte : HostKey /etc/ssh_host_key HostKey /etc/ssh_host_rsa_key HostKey /etc/ssh_host_dsa_key
Vous reconnaîtrez sans doute les fichiers que nous
avons générés avec ssh-keygen dans l'étape pré-
cédente.
•    Le protocole SSH1 ne prévoit pas automatiquement de changement de clef de session en cours de connexion. Il est cependant possible de demander au serveur OpenSSH de le faire avec :
KeyRegenerationlnterval 3600 ServerKeyBits 768

Nous spécifions un intervalle de temps en secondes et une taille de clef.
•    Viennent ensuite des paramètres concernant l'au- thentification avec, dans l'ordre, le temps accordé à la procédure de login et le refus ou l'autorisation au root de se connecter :
LoginGraceTime 600 PermitRootLogin yes
Ici, le root a parfaitement le droit de se connecter à notre serveur et nous estimons que 600 secondes sont largement suffisantes pour qu'un utilisateur ait le temps de se loguer.
•    Nous entrons à présent dans le vif du sujet avec tout ce qui concerne les méthodes d'authentifica- tion des utilisateurs. Tout d'abord, nous devons choisir si, dans le cas du protocole SSH1, nous dési- rons une authentification RSA. Cette ligne ne concerne que le protocole SSH1 et permet de choi- sir entre une utilisation des clefs (rsal) ou une authentification par mot de passe classique
RSAAuthentication yes
Vous vous en serez douté, un yes autorise l'authen- tification rsal alors qu'un no l'interdit.
•    Voici l'équivalent pour le protocole SSH2 avec authentification par clefs rsa ou dsa:
PubkeyAuthentication yes
•    Cette option qui va suivre ne devrait en aucun cas être mise à yes. Elle permet, en effet, une méthode d'authentification qui est loin d'être satisfaisante en termes de sécurité. Le principe est le même que pour le mécanisme rhost où, une fois les deux machines en présence sûres de leur identité, la connexion s'établit sans aucune vérification supplé- mentaire. OpenSSH, avec le protocole SSH1 ou SSH2, permet de faire la même chose de manière beaucoup plus sécurisée et surtout, avec une gestion des utilisateurs. Vous comprendrez alors que nous ne souhaitons pas faire usage de cette fonctionnalité :
RhostsAuthentication no
D'ailleurs, par la même occasion, nous ne prenons pas même le temps de lire les fichiers en cause
IgnoreRhosts yes
Nous ne voulons pas même de la version utilisant un système rshost basé sur RSA RhostsRSAAuthentication no
Idem pour le protocole SSH2 : HostbasedAuthentication no
•    Nous avons parlé de l'authentification RSA (SSH1) et Pubkey (SSH2), mais dans la phase de test, en cas de problème, nous souhaitons disposer d'une solution de rabattage utilisant le bon vieux système de mots de passe
PasswordAuthentication yes
Cependant, nous ne sommes pas assez fous pour autoriser la connexion sur des comptes ne possé- dant pas de mot de passe :
PermitEmptyPasswords no
•    Il nous reste à configurer quelques éléments concernant les fonctionnalités à disposition après la phase d'authentification. Nous commençons par autoriser le tunneling de l'affichage X11 déporté et le display à mettre en place (voir article sur le déportage d'affichage dans le présent numéro) :
Xl1Forwarding yes Xl1DisplayOffset 10
Toujours concernant la session alors qu'elle est déjà ouverte, l'option suivante permet, si elle est activée, d'envoyer régulièrement un message afin de tester la connexion. Ceci permet d'éviter que, si le client dis- paraît, la connexion reste ouverte indéfiniment
KeepAlive yes
Côté client, le fichier /usr/local/etc/ssh_
config ou —/ . ssh/config peut parfaitement être vide. Dans ce cas, le client essayera de s'adapter au mieux aux fonctionnalités du serveur.
Donc, en principe, vous pouvez vous passer de personnaliser le fichier de configuration du client. Cependant, la structure du fichier de configuration permet d'automatiser un grand nombre d'éléments et ce, en fonction du serveur que vous allez contacter.