Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Chapitre 10. OpenSSH

SSH (Secure Shell) est un protocole qui facilite les communications sécurisées entre deux systèmes en utilisant une architecture client-serveur, et qui permet aux utilisateurs de se connecter à des systèmes hôtes de serveur à distance. À la différence d'autres protocoles de communication à distance tels que FTP ou Telnet, SSH codifie la session de connexion, ce qui la rend difficile d'accès aux intrus qui souhaiteraient récupérer les mots de passe.
Le programme ssh est conçu pour remplacer les applications de terminal les plus anciennes et les moins sécurisées qui sont utilisées pour la connexion à des hôtes distants, comme telnet ou rsh. Un programme connexe appelé scp remplace les anciens programmes conçus pour copier des fichiers entre les ordinateurs hôtes, comme rcp. Comme ces applications plus anciennes ne cryptent pas les mots de passe qui sont transmis entre le client et le serveur, évitez-les autant que possible. En utilisant des méthodes sûres pour vous connecter à des systèmes distants, vous diminuez les risques pour le système client et l'hôte distant à la fois.
Red Hat Enterprise Linux comprend le paquet OpenSSH général, openssh, ainsi que les paquets de serveur, openssh-server et des clients, openssh-clients. Noter que les paquets OpenSSH exigent la présence du paquet OpenSSL openssl-libs, qui installe plusieurs bibliothèques cryptographiques importantes, ce qui permet à OpenSSH de fournir des communications cryptées

10.1. Le protocole SSH

10.1.1. Pourquoi utiliser SSH ?

Les intrus potentiels ont une variété d'outils à leur disposition leur permettant de perturber, intercepter et re-router le trafic réseau dans le but d'accéder à un système. En règle générale, ces menaces peuvent être classées ainsi :
Interception de communication entre deux systèmes
L'attaquant peut être quelque part sur le réseau entre les parties communicantes, copiant des informations passées entre elles. Il peut intercepter et maintenir l'information, ou la modifier et l'envoyer à des destinataires designés.
Cette attaque est généralement réalisée à l'aide d'un renifleur de paquets (packet sniffer), un utilitaire de réseau plutôt commun, qui capte chaque paquet qui passe à travers le réseau et qui en analyse le contenu.
Emprunt d’identité d'un hôte particulier
Le système de l'attaquant est configuré pour se poser en tant que destinataire d'une transmission. Si cette stratégie fonctionne, le système de l'utilisateur ne sait pas qu'il communique avec le mauvais hôte.
Cette attaque peut être effectuée par une technique appelée un empoisonnement DNS, ou via ce que l'on appelle une usurpation d'adresse IP. Dans le premier cas, l'intrus utilise un serveur DNS qui aura failli dans le but de pointer les systèmes client à un hôte qui aura été malicieusement dupliqué. Dans le second cas, l'intrus envoie des paquets réseau falsifiés qui semblent provenir d'un hôte de confiance.
Les deux techniques interceptent des informations sensibles potentiellement, et, si l'interception a lieu à des fins hostiles, les résultats peuvent être désastreux. Si SSH est utilisé pour la connexion à un shell distant et pour la copie de fichiers, ces menaces à la sécurité peuvent être grandement diminuées. C'est parce que le client SSH et le serveur utilisent des signatures numériques pour vérifier leur identité. En plus, toutes les communications entre les systèmes client et serveur sont cryptées. Les tentatives d'usurpation l'identité de part et d'autre d'une communication ne fonctionnent pas, puisque chaque paquet est crypté à l'aide d'une clé connue seulement par les systèmes locaux et distants.

10.1.2. Fonctionnalités principales

Le protocole SSH offre les avantages suivants :
Personne ne peut se faire passer pour un serveur intentionnel
Après avoir effectué une connexion initiale, le client peut s'assurer que sa connexion est établie avec le même serveur que lors de sa session précédente.
Personne ne peut récupérer les données d'authentification
Le client transmet ses données d'authentification au serveur au moyen d'un chiffrement solide de 128 bits.
Personne ne peut intercepter la communication
Toutes les données envoyées et reçues lors d'une session sont transférées au moyen d'un chiffrement 128 bits, rendant ainsi le déchiffrement et la lecture de toute transmission interceptée extrêmement difficile.
De plus, il offre les options suivantes :
Il fournit des moyens sûrs d'utiliser les applications graphiques par l'intermédiaire d'un réseau.
En utilisant une technique appelée X11 forwarding, le client peut envoyer des applications X11 (X Window System) en partance du serveur.
Cela fournit un moyen de sécuriser des protocoles non sécurisés normalement
Le protocole SSH crypte tout ce qu'il envoie et reçoit. En utilisant une technique appelée port forwarding, un serveur SSH peut devenir un moyen de sécuriser des protocoles normalement non protégés, comme POP, tout en augementant la sécurité des données et du système en général.
Il peut être utilisé pour créer un canal sécurisé
Le serveur OpenSSH et le client peuvent être configurés afin de créer un tunnel semblable à un réseau virtuel privé pour permettre le trafic entre le serveur et les machines clientes.
Il prend en charge l'authentification Kerberos
Les clients et serveurs OpenSSH peuvent être configurés pour authentifier par l'interface GSSAPI (Generic Security Services Application Program Interface) du protocole d'authentification du réseau Kerberos.

10.1.3. Versions de protocole

Il existe actuellement deux sorts de SSH : version 1 et version 2 plus récente. La suite OpenSSH sous Red Hat Enterprise Linux utilise SSH la version 2, qui dispose d'un algorithme d'échange de clés amélioré non vulnérable à l'exploitation connue pour la version 1. Toutefois, pour des raisons de compatibilité, la suite OpenSSH prend en charge les connexions de la version 1 également.

Important

Pour assurer un maximum de sécurité au niveau de votre connexion, il est conseillé que seuls les clients et serveurs compatibles avec SSH version 2 soient utilisés si possible.

10.1.4. Séquence d'événements d'une connexion SSH

Pour aider à protéger l'intégrité d'une communication SSH entre deux ordinateurs hôte, la série suivante d'événements doit être utilisée.
  1. Une liaison cryptographique est établie afin de permettre au client de vérifier qu'il est bien en communication avec le serveur souhaité.
  2. La couche de transport de la connexion entre le client et tout hôte distant est chiffrée au moyen d'un moyen de chiffrement symétrique.
  3. Le client s'authentifie auprès du serveur.
  4. Le client peut interagir avec l'hôte distant au moyen d'une connexion chiffrée.

10.1.4.1. Couche de transport

Le rôle principal de la couche de transport est de faciliter une communication sécurisée entre deux hôtes non seulement au moment de l'authentification, mais également lors de communications ultérieures. Pour ce faire, la couche de transport traite le cryptage et décryptage de données et offre une certaine protection quant à l'intégrité des paquets de données lors de leur envoi et de leur réception. De plus, la couche de transport effectue la compression des données permettant d'accélérer la vitesse de transfert des informations.
Lorsqu'un client communique avec un serveur au moyen d'un protocole SSH, de nombreux éléments importants sont échangés afin que les deux systèmes puissent créer correctement la couche de transport. Lors de cet échange, les opérations suivantes ont lieu :
  • Des clés sont échangées.
  • L'algorithme de chiffrement de clés publiques est déterminé
  • L'algorithme de chiffrement symétrique est déterminé
  • L'algorithme d'authentification de message est déterminé
  • L'algorithme de hachage est déterminé
Au cours de l'échange de clés, le serveur s'identifie au client par une clé d'hôte unique. Si le client n'a jamais communiqué avec ce serveur particulier auparavant, la clé du serveur hôte est inconnue au client et il ne se connecte pas. OpenSSH contourne ce problème en acceptant la clé du serveur hôte. Ceci est fait après que l'utilisateur ait été informé et a à la fois accepté et vérifié la nouvelle clé de l'hôte. Dans les connexions suivantes, la clé du serveur hôte est vérifiée par rapport la version enregistrée sur le client, pour s'assurer que le client communique avec le serveur voulu. Si, dans l'avenir, la clé de l'hôte ne correspond plus, l'utilisateur doit supprimer la version du client enregistrée avant qu'une connexion puisse avoir lieu.

Avertissement

Il est tout à fait possible pour un pirate de se faire passer pour le serveur SSH lors de la première connexion car le système local ne détecte aucune différence entre le serveur désiré et le faux serveur créé par le pirate. Afin d'éviter une telle situation, contrôlez l'intégrité d'un nouveau serveur SSH en contactant l'administrateur du serveur avant d'établir la première connexion au cas où une clé d'hôte ne correspond pas à celle stockée sur le serveur.
Le protocole SSH est conçu pour fonctionner avec n'importe quel algorithme de clé publique ou tout format de codage. Après que l'échange initial des clés crée une valeur de hachage utilisée pour les échanges et une valeur secrète partagée, les deux systèmes commencent immédiatement à calculer de nouveaux algorithmes et de nouvelles clés pour protéger l'authentification et les futures données envoyées via la connexion.
Après la transmission d'une certaine quantité de données au moyen d'une clé et d'un algorithme précis (la quantité exacte dépend de l'implémentation du protocole SSH), un nouvel échange de clés est effectué ; cette opération engendre la création d'un autre ensemble de valeurs de hachage et d'une autre valeur secrète partagée. De cette façon, même si un pirate réussit à déterminer les valeurs de hachage et la valeur secrète partagée, ces informations ne lui seront utiles que pour une durée limitée.

10.1.4.2. Authentification

Une fois que la couche de transport a créé un tunnel sécurisé pour envoyer les informations entre les deux systèmes, le serveur indique au client les différentes méthodes d'authentification prises en charge, telles que l'utilisation d'une signature dotée d'une clé codée ou la saisie d'un mot de passe. Le client doit ensuite essayer de s'authentifier auprès du serveur au moyen d'une des méthodes spécifiées.
Les serveurs et clients SSH peuvent être configurés de façon à permettre différents types d'authentification, donnant à chacune des deux parties un niveau de contrôle optimal. Le serveur peut décider des méthodes de cryptage qu'il prend en charge en fonction de son modèle de sécurité et le client peut choisir l'ordre des méthodes d'authentification à utiliser parmi les options disponibles.

10.1.4.3. Canaux

After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called multiplexing[1]. Each of these channels handles communication for different terminal sessions and for forwarded X11 sessions.
Le client et le serveur peuvent créer un nouveau canal. Chaque canal reçoit ensuite un numéro différent à chaque extrémité de la connexion. Lorsque le client essaie d'ouvrir un nouveau canal, il envoie le numéro du canal accompagné de la requête. Ces informations sont stockées par le serveur et utilisées pour diriger la communication vers ce canal. Cette procédure est utilisée afin que des types différents de session ne créent pas de nuisances mutuelles et de sorte qu'à la fin d'une session donnée, son canal puisse être fermé sans que la connexion SSH principale ne soit interrompue.
Les canaux prennent aussi en charge le contrôle du flux de données, ce qui leur permet d'envoyer et de recevoir des données de façon ordonnée. Ce faisant, aucune donnée n'est envoyée sur le canal tant que l'hôte n'a pas reçu de message lui indiquant que le canal est ouvert.
Le client et le serveur négocient automatiquement la configuration de chaque canal, selon le type de service demandé par le client et la manière dont l'utilisateur est connecté au réseau. Ainsi, le traitement des différents types de connexions distantes est non seulement extrêmement flexible, mais il ne nécessite pas même d'apporter des modifications à la structure de base du protocole.

[1] A multiplexed connection consists of several signals being sent over a shared, common medium. With SSH, different channels are sent over a common secure connection.