4.2. SSH : sécurisation des opérations réseau

Avec l'installation croissante d'ordinateurs dans des environnements réseau, il devient souvent nécessaire d'accéder aux hôtes depuis un emplacement distant. Cela signifie généralement qu'un utilisateur envoie des chaînes de connexion et de mot de passe en vue d'une authentification. Si ces chaînes sont transmises en texte clair, elles peuvent être interceptées et être utilisées de façon malveillante pour accéder à un compte utilisateur sans que l'utilisateur autorisé ne s'en aperçoive. Outre la possibilité d'ouverture de tous les fichiers par un pirate informatique, le compte détourné peut être utilisé pour obtenir un accès en tant qu'administrateur ou root ou pour forcer d'autres systèmes. Auparavant, les connexions distantes étaient établies avec telnet, qui n'offre aucune protection contre les écoutes sous forme de codage ou d'autres mécanismes de sécurité. D'autres voies de communication non protégées existent, comme le protocole FTP classique et certaines programmes de copie à distance.

La suite SSH offre une protection nécessaire en codant les chaînes d'authentification (généralement un nom de connexion et un mot de passe) et toutes les autres données échangées entre les hôtes. Avec SSH, le flux de données peut toujours être enregistré par un tiers, mais le contenu est codé et ne peut pas être redéfini en texte clair sauf si la clé de codage est connue. SSH offre donc une communication sécurisée sur des réseaux non protégés comme Internet. La version SSH de SUSE Linux est OpenSSH.

4.2.1. Le paquetage OpenSSH

SUSE Linux installe le paquetage OpenSSH par défaut. Les programmes ssh, scp et sftp sont ensuite disponibles comme alternatives à telnet, rlogin, rsh, rcp et ftp. Dans la configuration par défaut, l'accès à un système SUSE Linux n'est possible qu'à l'aide des utilitaires OpenSSH et seulement si le pare-feu en autorise l'accès.

4.2.2. Le programme ssh

Le programme ssh permet de se connecter à des systèmes distants et de travailler de manière interactive. Ce programme remplace telnet et rlogin. Le programme slogin est seulement un lien symbolique vers ssh. Par exemple, connectez-vous à l'hôte Sun avec la commande ssh sun. L'hôte vous invite alors à saisir le mot de passe sur l'hôte Sun.

Une fois l'authentification réussie, vous pouvez travailler sur la ligne de commande distante ou utiliser des applications interactives, telles que YaST. Si le nom d'utilisateur local est différent du nom d'utilisateur distant, vous pouvez vous connecter avec un nom de connexion différent en utilisant ssh -l augustine sun ou ssh augustine@sun.

En outre, ssh offre la possibilité d'exécuter des commandes sur des systèmes distants, tels que rsh. Dans l'exemple suivant, exécutez la commande uptime sur l'hôte Sun, puis créez un répertoire que vous appelez tmp. Le résultat du programme s'affiche sur le terminal local de l'hôte Earth.

ssh otherplanet "uptime; mkdir tmp" 
tux@otherplanet's password:
1:21pm  up  2:17,  9 users,  load average: 0.15, 0.04, 0.02

Les guillemets servent ici à envoyer les instructions à l'aide d'une commande. La deuxième commande est exécutée sur Sun grâce à cette action.

4.2.3. scp—Copie sécurisée

scp copie les fichiers vers un ordinateur distant. Il permet de remplacer rcp tout en offrant une sécurisation et un codage. Par exemple, scp MyLetter.tex sun: copie le fichier MyLetter.tex de l'hôte Earth vers l'hôte Sun. Si le nom d'utilisateur sur l'hôte Earth est différent du nom d'utilisateur sur l'hôte Sun, spécifiez ce dernier au format username@host. Il n'existe pas d'option -l pour cette commande.

Une fois le mot de passe correct saisi, scp commence le transfert des données et affiche une ligne croissante d'astérisques pour simuler une barre de progression. Par ailleurs, le programme affiche une estimation du temps d'arrivée à droite de la barre de progression. Supprimez toutes les sorties en cochant l'option -q.

scp est également doté d'une fonction de copie récursive pour des répertoires entiers. La commande scp -r src/ sun:backup/ copie l'intégralité du contenu du répertoire src, y compris les sous-répertoires, dans le répertoire backup sur l'hôte Sun. Si le sous-répertoire n’existe pas, il est créé automatiquement.

L'option -p indique à scp de ne pas modifier le tampon horaire des fichiers. -C compresse le transfert des données, ce qui permet de réduire la quantité de données à transférer, mais ce qui crée une charge importante sur le processeur.

4.2.4. sftp—Sécurisation du transfert de fichiers

Le programme sftp peut être utilisé à la place de scp pour transférer les fichiers en toute sécurité. Lors d'une session sftp, vous pouvez utiliser la plupart des commandes connues de ftp. Il est sans doute préférable d'utiliser sftp au lieu de scp, surtout lors du transfert des données pour lesquelles les noms de fichiers ne sont pas connus.

4.2.5. Le démon SSH (sshd)—Côté serveur

Pour utiliser les programmes clients de SSH ssh et scp, un serveur, le démon SSH, doit s'exécuter en arrière-plan. Il écoute les connexions sur TCP/IP port 22. Le démon génère trois paires de clés lors du premier démarrage. Chaque paire de clés comprend une clé privée et une clé publique. Cette procédure est donc basée sur les clés publiques. Pour garantir la sécurité de la communication via SSH, l'accès aux fichiers de clé privé doit être réservé à l'administrateur système. Les autorisations d'accès aux fichiers sont définies en fonction de l'installation par défaut. Les clés privées sont uniquement requises en local par le démon SSH. Elles ne doivent être communiquées à personne d'autre. Les composants de clé publique (identifiés par l'extension .pub) sont envoyés au client qui fait une demande de connexion. Ils peuvent être lus par tous les utilisateurs.

Une connexion est lancée par le client SSH. Le démon SSH en attente et le client SSH demandeur échangent des données d'identification pour comparer le protocole et les versions logicielles et pour empêcher les connexions via un port incorrect. Étant donné qu'un processus enfant du démon SSH original répond à la requête, il est possible d'établir plusieurs connexions SSH simultanément.

Pour établir une communication entre le serveur SSH et le client SSH, OpenSSH prend en charge les versions 1 et 2 du protocole SSH. Le tout nouveau système SUSE Linux installé est configuré sur la version 2. Pour continuer à utiliser la version 1 après une mise à jour, suivez les instructions contenues dans /usr/share/doc/packages/openssh/README.SuSE. Ce document décrit également la manière dont un environnement SSH 1 peut être transformé en environnement de travail SSH 2 en seulement quelques étapes.

Lorsque vous utilisez la version 1 de SSH, le serveur envoie sa clé hôte publique et une clé du serveur qui est régénérée par le démon SSH toutes les heures. Ces deux clés permettent au client SSH de coder une clé de session arbitraire qui est envoyée au serveur SSH. Le client SSH indique également au serveur la méthode de codage (cipher) à utiliser.

La version 2 du protocole SSH ne requiert pas de clé de serveur. Les deux côtés utilisent un algorithme conformément à Diffie-Helman pour échanger leurs clés.

Les clés de serveur et d'hôte privées sont absolument requises pour décoder la clé de session et ne peuvent pas provenir de composants publics. Seul le démon SSH contacté peut décoder la clé de session à l'aide de ses clés privées (reportez-vous à man /usr/share/doc/packages/openssh/RFC.nroff). Vous pouvez examiner de près la phase de connexion initiale en activant l'option de débogage verbose -v du client SSH.

La version 2 du protocole SSH est utilisée par défaut. Remplacez-la par la version 1 du protocole avec l'interrupteur -1. Le client enregistre toutes les clés hôte publiques dans ~/.ssh/known_hosts après son premier contact avec un hôte distant. Cela empêche des attaques de l'intercepteur, comme des tentatives par des serveurs SSH étrangers d'utiliser des noms et des adresses IP usurpés. Ces attaques sont détectées par une clé hôte non incluse dans ~/.ssh/known_hosts ou par l'impossibilité du serveur de décoder la clé de session en l'absence d'un équivalent privé approprié.

Il est recommandé de sauvegarder les clés privées et publiques stockées dans /etc/ssh/ dans un emplacement sûr et externe. De cette manière, les modifications apportées aux clés peuvent être détectées et les anciennes clés peuvent être utilisées à nouveau après une réinstallation. Ainsi, vous ne verrez plus s'afficher des avertissements déstabilisants. S'il a été vérifié que, malgré l'avertissement, il s'agit effectivement du serveur SSH correct, l'entrée existante du système doit être supprimée de ~/.ssh/known_hosts.

4.2.6. Mécanismes d'authentification SSH

Désormais, l'authentification, dans sa forme la plus simple, consiste à saisir un mot de passe comme mentionné ci-dessus. L'objectif de SSH était d'introduire un logiciel sécurisé également facile à utiliser. Conçu pour remplacer rsh et rlogin, SSH doit également fournir une méthode d'authentification appropriée pour une utilisation quotidienne. Pour ce faire, SSH utilise une autre paire de clés qui est générée par l'utilisateur. Le paquetage SSH offre un programme d'aide à cette fin : ssh-keygen. Après avoir saisi ssh-keygen -t rsa ou ssh-keygen -t dsa, la paire de clés est générée. Vous êtes alors invité à saisir le nom de fichier de base dans lequel vous pouvez stocker les clés.

Confirmez le réglage par défaut et répondez à la requête qui vous invite à saisir une phrase secrète. Même si le logiciel propose une phrase secrète vide, un texte de 10 à 30 caractères est recommandé pour la procédure décrite ici. N'utilisez pas de phrases ni de mots simples et courts. Confirmez en répétant la phrase secrète. Vous verrez par la suite le lieu de stockage des clés privées et publiques, dans cet exemple les fichiers id_rsa et id_rsa.pub.

Utilisez ssh-keygen -p -t rsa ou ssh-keygen -p -t dsa pour modifier votre ancienne phrase secrète. Copiez le composant de clé publique (id_rsa.pub dans l'exemple) vers l'ordinateur distant et enregistrez-le vers ~/.ssh/authorized_keys. Il vous sera demandé de vous authentifier avec votre phrase secrète lors de votre prochaine connexion. Si tel n'est pas le cas, vérifiez l'emplacement et le contenu de ces fichiers.

Sur le long terme, cette procédure est plus ennuyeuse que de saisir votre mot de passe à chaque fois. Par conséquent, le paquetage SSH offre un autre outil, l'agent ssh, qui conserve les clés privées pendant la durée d'une session X. Toute la session X est lancée en tant que processus enfant de l'agent ssh. Le moyen le plus facile est de régler la variable usessh au début du fichier .xsession sur yes et de vous connecter via un gestionnaire d'affichage, tel que KDM ou XDM. Vous pouvez également saisir ssh-agent startx.

Vous pouvez désormais utiliser ssh ou scp comme d'habitude. Si vous avez distribué votre clé publique comme décrit ci-dessus, vous n'avez plus besoin de saisir votre mot de passe. Veillez à fermer votre session X ou à la verrouiller à l'aide d'une application de protection par mot de passe, telle que xlock.

Toutes les modifications pertinentes résultant de l'introduction de la version 2 du protocole SSH sont également documentées dans le fichier /usr/share/doc/packages/openssh/README.SuSE.

4.2.7. Mécanismes X, d'authentification et de transfert

Au-delà des améliorations liées à la sécurité décrites précédemment, SSH simplifie également l'utilisation d'applications X distantes. Si vous exécutez ssh avec l'option -X, la variable DISPLAY est automatiquement réglée sur la machine distante et toutes les sorties X sont exportées vers la machine distante sur la connexion SSH existante. Simultanément, les applications X lancées à distance ou en local affichées avec cette méthode ne peuvent pas être interceptées par des utilisateurs non autorisés.

En ajoutant l'option -A, le mécanisme d'authentification ssh-agent est reporté vers la machine suivante. Ainsi, vous pouvez utiliser plusieurs machines sans avoir besoin de saisir un mot de passe, mais seulement si vous avez distribué votre clé publique aux hôtes de destination et si vous l'avez sauvegardée correctement à cet endroit.

Les deux mécanismes sont désactivés dans la configuration par défaut, mais peuvent être activés de façon permanente à tout moment dans le fichier de configuration pour l'ensemble du système /etc/ssh/sshd_config ou le fichier ~/.ssh/config de l'utilisateur.

ssh peut également être utilisé pour rediriger les connexions TCP/IP. Dans les exemples ci-dessous, il est indiqué à SSH de rediriger SMTP et le port POP3 respectivement :

ssh -L 25:sun:25 earth

Avec cette commande, toute connexion dirigée vers le port Earth 25 (SMTP) est redirigée vers le port SMTP sur Sun via un canal codé. Cela s'avère particulièrement pratique pour les personnes qui utilisent les serveurs SMTP sans les fonctions SMTP-AUTH ou POP-before-SMTP. Depuis un emplacement arbitraire connecté à un réseau, un message électronique peut être transféré vers le serveur de messagerie « home ». De même, toutes les requêtes POP3 (port 110) sur l'hôte Earth peuvent être transférées vers le port POP3 de l'hôte Sun avec cette commande.

ssh -L 110:sun:110 earth

Les deux commandes doivent être exécutées en tant qu'utilisateur root. La connexion est en effet établie vers les ports locaux privilégiés. Le message électronique est envoyé et récupéré par des utilisateurs normaux dans une connexion SSH existante. Pour réussir cette opération, les hôtes SMTP et POP3 doivent être définis sur localhost. Vous trouverez des informations supplémentaires dans les pages de manuel pour chacun des programmes décrits ci-dessus, mais aussi dans les fichiers sous /usr/share/doc/packages/openssh.