PROTOCOLE SSH

• 1. Introduction et évolution du protocole SSH

• 1.1 L’authentification
• 1.2 La confidentialité des données
• 1.3 L’intégrité des données
• 1.4 L’évolution du protocole SSH

• 2. L’architecture et le fonctionnement de base

2.1 Les sous-protocoles de SSH
2.2 La phase d’initialisation de SSH
2.3 Les différentes méthodes d’authentification avec SSH
2.3.1 L’authentification par mot de passe (password)
2.3.2 L’authentification par clef RSA ou DSA (publickey)
2.3.3 L’authentification par hôte (hostbased)
2.3.4 L’authentification par certificat X.509
3. Les fonctionnalités offertes par SSH
3.1 L’accès à distance par le shell SSH
3.2 Le transfert de fichiers par SFTP
3.3 Le tunneling
3.4 La redirection de ports (Port forwarding)
3.5 La redirection de l’authentification (Agent forwarding)

4. SSH vs les autres solutions VPN

5. Les limites du protocole SSH

5.1 La première authentification non sécurisée du client avec le serveur SSH
5.2 Les attaques sur le mot de passe
5.3 L’authentification non sûre par « hôte de confiance »
5.4 SSH et la traduction des adresses réseau (NAT)

6. Les principales distributions de SSH

7. L’avenir de l’exploitation du protocole SSH
8.Conclusion
INTRODUCTION
• Le protocole SSH (Secure Shell) est utilisé pour établir un accès sécurisé
permettant d’effectuer des opérations sensibles sur des machines
distantes et d’effectuer des transferts de fichiers à travers un réseau
publique tout en garantissant l’authentification, la confidentialité et
l’intégrité des données.

• Le principal objectif de SSH était de résoudre le problème de transmission

en clair de toutes les informations sur le réseau (LAN ou Internet) ouvrant
la porte à toutes les attaques de type homme du milieu (Man-in-The-
Middle).

• Depuis l’apparition de SSH, son rôle a évolué pour ne pas se limiter à une
simple fonctionnalité de connectivité à distance pour le shell. La version 2
de ce protocole, normalisée en janvier 2006, propose la sécurisation de
n’importe quel protocole applicatif et ceci grâce à ses mécanismes de
« port forwarding » et de « tunneling ».
• Dans ce dossier, nous allons expliquer les différents services de sécurité
mis en place dans SSH tout en se focalisant sur sa version 2, normalisée en
2006 à l’IETF. Nous présenterons par la suite, les sous-protocoles de
SSHv2, sa phase d’initialisation et les différentes méthodes
d’authentification qui y sont intégrées. Nous aborderons aussi la solution
SSH VPN en la comparant à IPSec et SSL. Nous discuterons ensuite de
l’avenir du protocole SSH et des nouveaux standards TLS qui influencent
l’avenir de ce protocole et son actuelle utilisation dans l’accès aux
équipements distants. Nous terminerons le dossier par une conclusion.

• Remerciements :

• Nous remercions le Pr. Maryline Maknavicius-Laurent et le Dr. Ouahiba

Fouial pour l’attention qu’elles ont accordée à ce dossier, pour le temps
qu’elles ont bien voulu consacrer à sa lecture et enfin, pour leurs
remarques constructives et intéressantes
Principaux sigles
PPTP : Point-to-Point Tunneling
AC : Autorité de Certification
Protocol (RFC 2647)
3DES : Triple DES (ANSI X9.52) PKI : Public Key Infrastructure
Arcfour : Allegedly RC4 (version
PFS : Perfect Forward Secrecy
publique de RC4)
CRC : Cyclic Redundancy Check PRF : Pseudo-Random Function
DES : Data Encryption Standard RC2 : Rivest Cipher, version 2 (RFC
(ANSI INCITS 92) 2268)
DSA : Digital Signature Algorithm
RFC : Request For Comments
(FIPS 186-2)
RSA : Rivest, Shamir et Adleman
HMAC : Keyed-Hashing for Message
(entré dans le domaine publique depuis
Authentication Codes (RFC 2104)
sept. 2000)
HTTP : HyperText Transfer Protocol
RSH : Remote Shell
(RFC 2616)
 SHA-1 : Secure Hash Algorithm,
DH : Diffie et Hellman
version 1 (NIST FIPS 180-2)

FTP : File Transfer Protocol (RFC 959) SFTP : Secure File Transfer Protocol

IETF : Internet Engineering Task Force

SFTP : Secure File Transfer Protocol
(IETF draft http://www.ietf.org/internet-
IP : Internet Protocol (sous-entendu drafts/draft-ietf-secsh-filexfer-12.txt)
version 4, RFC 791)

SMTP : Simple Mail Transfer Protocol

IPSec : IP Security
(RFC 788)

ITU : International Telecommunications SOCKS : SOCKet Secure (IETF

Union RFC1928)

MD5 : Message Digest version 5 SSH : Secure Shell

NAT : Network Address Translation
SSL : Secure Socket Layer
(RFC 2663)

POP3 : Post Office Protocol, version 3 TLS : Transport Layer Security (RFC
(RFC 1081) 2246)

TCP : Transmission Control Protocol (RFC

793)
PPP : Point-to-Point Protocol (RFC 1661)

VPN : Virtual Private Network

Pour avoir davantage d’informations sur chacun de ces sigles, le lecteur pourra se
référer au site web de l’IETF (Internet Engineering Task Force) : http://www.ietf.org à la
page suivante : http://www.ietf.org/rfc.html.
 1. Introduction et évolution du protocole SSH

• 1.1 L’authentification
•
1.2 La confidentialité des données
•
1.3 L’intégrité des données
•
1.4 L’évolution du protocole SSH
• Le protocole SSH, ou Secure Shell, a été développé en 1995 par Tatun
Ylönen, un professeur finlandais qui, à l’époque, souhaitait sécuriser les
connexions distantes vers un serveur Unix via des commandes telles que
telnet, rlogin, copy, etc.

• SSH est à la fois un protocole et un ensemble de programmes utilisant ce

protocole. Il permet aux utilisateurs d’ouvrir, depuis une machine cliente,
des sessions interactives avec des serveurs distants et de transférer des
fichiers entre les deux. SSH utilise le protocole SOCKS v5 intégré dans la
plupart des équipements réseaux, pour établir des communications
sécurisées de bout en bout. Les applications basées sur SOCKS v5 offrent
de nombreux avantages reposant sur son architecture protocolaire
robuste et flexible.

• La dernière version de SSH, normalisée en janvier 2006 à l’IETF, est la

version 2.0. Elle intègre notamment de nouveaux algorithmes et des
services comme le transfert de fichiers SFTP, le tunneling, le port
forwarding, l’authentification via des clefs privées sécurisées et bientôt
l’utilisation des certificats X.509.
• SSH fournit principalement trois services de sécurité : l’authentification, la
confidentialité et l’intégrité des données. L’objectif de SSH est en effet de
protéger tous ses échanges contre :

• les écoutes effectuées sur le canal de communication, et cela grâce au

chiffrement des flux ;

• les manipulations des données transmises à travers le canal de

communication ;

• l’IP spoofing (usurpation d’une adresse IP) où une machine attaquante

prétend être une autre machine de confiance, et ceci grâce à des clefs
asymétriques permettant d’authentifier les machines client et serveur
SSH ;

• le DNS spoofing où l’attaque vise à faire parvenir de fausses réponses aux

requêtes DNS émises par une victime, de manière à rediriger des
connexions vers une machine contrôlée par l’attaquant ;
• l’IP Source Routing où une machine attaquante peut faire croire qu’un
paquet provient d’un autre hôte ;
le TCP hijaking (vol de connexion) grâce au contrôle d’intégrité de SSH qui
permet de détecter si une session a été modifiée ;
les attaques de type Man-in-The-Middle grâce à l’authentification du
serveur hôte.
Dans la suite de ce dossier, nous allons expliquer les différents services de
sécurité mis en place dans SSH, puis les différences entre les deux
versions 1 et 2 de SSH. Le paragraphe 2 présente ensuite l’organisation en
sous-protocoles de SSH v2 et le fonctionnement du protocole SSH v2 avec
une description détaillée de la phase d’initialisation de ce protocole ainsi
que les différentes méthodes d’authentification qui y sont intégrées. Dans
la seconde partie, nous décrivons les fonctionnalités offertes par ce
protocole. Puis, nous abordons la solution SSH VPN en la comparant à
IPSec et SSL, les limites du protocole SSH ainsi que les principales
distributions de ce protocole. Nous discutons ensuite de l’avenir du
protocole SSH et des nouveaux standards TLS qui influencent l’avenir de ce
protocole et son actuelle utilisation dans l’accès aux équipements distants.
Nous terminons l’article par une conclusion.
1.1 L’authentification
• Le service d’authentification permet d’assurer qu’une communication est
authentique. On peut distinguer deux types d’authentification :
l’authentification d’un tiers et l’authentification de la source des données.

• L’authentification d’un tiers consiste, pour ce dernier, à prouver son

identité.

• L’authentification de la source des données sert à prouver que les

données reçues viennent bien de l’émetteur déclaré. Dans les systèmes
Unix, le moyen le plus commun d’authentifier des utilisateurs est d’utiliser
des mots de passe.

• Les protocoles tels que telnet, ftp, et rsh, transmettent en clair les mots de
passe des utilisateurs. Cela signifie qu’ils peuvent facilement être
espionnés et exploités par n’importe quelle personne écoutant le réseau.
SSH améliore la sécurité en chiffrant n’importe quel trafic utilisé pendant
l’authentification.
• Les mots de passe ne sont pas transférés en clair sur le réseau public. De
plus, l’avantage significatif de SSH est l’utilisation des clefs publiques RSA
(dans la version 1 du protocole) puis de l’algorithme DSA (dans la
version 2 de SSH) pour l’authentification des entités en communication.
Ce mécanisme de chiffrement asymétrique (encadré 1) est plus sûr que
l’authentification simple du couple nom de l’utilisateur/mot de passe
(user name/password). SSH supporte cependant d’autres méthodes
d’authentification qui seront détaillées dans les paragraphes suivants.

• Le chiffrement asymétrique, également appelé chiffrement à clef

publique, repose sur une paire de clefs : une clef publique (pour réaliser
le chiffrement de données confidentielles et la vérification de signature)
et une clef privée (pour le déchiffrement de données et la génération de
signature). Les deux clefs sont reliées mathématiquement, de sorte
qu’un message chiffré avec une clef ne peut être déchiffré qu’avec la
deuxième clef. Les deux algorithmes asymétriques les plus utilisés sont
RSA et DSA.
 1.3 L’intégrité des données

• L’intégrité se rapporte à la protection contre les changements et les

altérations. L’intégrité est assurée si les données émises sont identiques à
celles reçues. Des différences peuvent apparaître si quelqu’un tente de
modifier ces données ou tout simplement si un problème de
transmission/réception intervient.

• Les techniques utilisées pour détecter l’altération des données

comprennent classiquement les bits de parité, les checksums (CRC) ou
encore les fonctions de hachage (encadré 2) à sens unique telles que MD5
ou SHA-1. Ces mécanismes ne peuvent cependant pas garantir l’intégrité
dans l’absolu. En effet, il est possible que les données altérées aient la
même somme de contrôle et qu’ainsi que leur altération passe inaperçue.
Il est aussi possible qu’un attaquant modifie les données et recalcule le
résultat de la fonction de hachage (empreinte).

Pour que seul l’expéditeur soit capable de modifier l’empreinte, on utilise

des fonctions de hachage à clefs secrètes ou privées.
 Dans ce cas, on garantit à la fois l’intégrité et l’authentification. Ces deux
services de sécurité sont souvent fournis par les mêmes mécanismes pour
la simple raison qu’ils n’ont de sens qu’accompagnés l’un de l’autre (dans
le contexte d’un réseau peu sûr).

• Une fonction de hachage est une fonction mathématique qui calcule une
empreinte d’un message. Plus précisément, elle prend en entrée un
message M de longueur m quelconque et fournit en sortie un résultat
appelé empreinte, de taille fixe, calculé à partir de M. Les fonctions de
hachage les plus utilisées sont SHA-1 et MD5.
 1.4 L’évolution du protocole SSH

• Le protocole SSH existe en deux versions majeures. La version 1 qui se

décline en deux sous-versions 1.3 et 1.5, et la version 2 qui est plus
récente et qui corrige également quelques erreurs de conception de la
version 1. En effet, SSH v1 est la première version du protocole qui décrit,
sous la forme d’un « Internet draft » (projet Internet) à l’IETF, le
fonctionnement d’un logiciel déjà développé. Les limites de ce logiciel ont
été découvertes au fur et à mesure de son utilisation. Certains problèmes
ne pouvaient pas être corrigés sans perdre la compatibilité ascendante,
d’où l’apparition de SSH v2.

• Le groupe de travail à l’IETF qui s’occupe de Secure Shell (SECSH WG),

dirigé par Bill Sommerfeld, est alors lancé. En 1997, ce groupe a fourni le
premier draft IETF* pour le protocole SSH v2. En 2006, il a réussi à
normaliser le protocole SSH sous forme de trois « couches » (voir
figure 1) :
• 1. SSH Transport Layer Protocol (SSH-TRANS) ;
• 2. SSH Authentification Protocol (SSH-AUTH) ;
• 3. SSH Connection Protocol (SSH-CONN).

• Chacune de ces trois couches a fait l’objet d’un document de spécification

particulier, accompagné d’un quatrième document décrivant l’architecture
générale de ce protocole (SSH Protocol Architecture, SSH-ARCH).

• Nota :
• * Durant le développement de spécifications à l’IETF, un groupe de travail
établit une version du travail du document et qui reste disponible sous la
forme d’un draft Internet IETF (Projet Internet). Un draft IETF peut
demeurer à l’état draft pendant six mois, et les parties intéressées ont la
possibilité de le réviser et le commenter régulièrement.
Afin de mieux comprendre les principaux changements existants entre la
version 1.5 et la version 2 du protocole, nous les présentons dans le
tableau 1. Pour plus de détails sur les caractéristiques, le lecteur intéressé
pourra se référer au paragraphe 2 descriptif.
• Sans rentrer dans les détails, dans une session SSH v1, les deux entités SSH
utilisent les mêmes algorithmes cryptographiques et les mêmes clefs pour les
deux sens de communication alors que dans la version 2 de SSH, les deux
entités négocient séparément pour chaque sens les différents algorithmes,
évitant ainsi de nombreuses attaques par analyse de trafic sur la session SSH.
De plus, SSH v1 utilise une somme de contrôle ordinaire CRC-32 pour assurer
l’intégrité des données transmises. Ce procédé étant trop faible pour la
vérification des données, SSH v2 l’a remplacé par l’usage de la fonction HMAC.
Un autre changement majeur est le fait que SSH v1 était monolithique alors
que SSH v2 divise le protocole en trois « couches », le rendant plus modulaire
en séparant le processus d’authentification de l’établissement du canal de
communication.

Nous ajoutons aussi, que de nombreux mécanismes d’authentification ont été

abandonnés dans la version 2 de SSH, en particulier l’authentification Rhosts
jugée non sûre. En effet, SSH v1 pouvait invoquer automatiquement la
commande Unix rsh si un serveur distant ne disposait pas d’un serveur SSH.
Par suite du manque de sécurité de rsh, cette possibilité est délibérément
absente de SSH v2.
Figure 1 - Architecture de SSH v2.0
• Ainsi, et afin d’éviter l’ensemble des attaques connues sur la version 1 de
SSH, la plupart des sociétés préfèrent l’utilisation exclusive de la version 2
de ce protocole. Dans la suite de ce dossier, nous allons décrire plus en
détail la version 2 de SSH.
 2. L’architecture et le fonctionnement de
base
  2.1 Les sous-protocoles de SSH

2.2 La phase d’initialisation de SSH

2.3 Les différentes méthodes d’authentification avec SSH

2.3.1 L’authentification par mot de passe (password)

2.3.2 L’authentification par clef RSA ou DSA (publickey)

2.3.3 L’authentification par hôte (hostbased)

2.3.4 L’authentification par certificat X.509

 2.1 Les sous-protocoles de SSH

• SSH utilise une architecture client-serveur pour assurer l’authentification

des entités communicantes, et le chiffrement et l’intégrité de leurs
données transmises sur un réseau. Comme nous l’avons déjà indiqué, la
version 2 de ce protocole spécifie une architecture séparée en trois sous-
protocoles (ou couches) travaillant ensemble comme le montre la
figure 1 :

• La couche transport SSH (SSH-TRANS)

• C’est sur cette couche que reposent les deux autres couches SSH. SSH-
TRANS fournit l’authentification du serveur, la confidentialité et
l’intégrité des données au moyen d’un chiffrement symétrique (cf.
encadré 3). Elle fournit en option la compression des données de session
en utilisant le mécanisme zlib (LZ77) défini dans les IETF RFC 1950 et 1951
(voir http://www.ietf.org). Cette couche doit être utilisée pour permettre
au client de vérifier qu’il communique bien avec le serveur attendu.
• Ce protocole fonctionne au-dessus de TCP/IP mais peut être utilisé au-
dessus de toute couche de transport fiable. Il effectue : l’authentification
du serveur, la négociation des algorithmes de protection des données, la
mise en place d’une clef de session, la création d’un secret partagé,
l’intégrité et la confidentialité des données et l’identification de la session.
• Le chiffrement symétrique, à clef secrète ou à simple clef, consiste à
utiliser la même clef pour le chiffrement et le déchiffrement d’un message
M. Il consiste à appliquer une opération (algorithme) sur les données à
chiffrer à l’aide de la clef secrète, afin de les rendre inintelligibles. Cette
même clef servira aussi pour le déchiffrement des messages chiffrés.
 Caractéristiques des versions 1 et 2 de SSH
SSH v1 SSH v2

Séparation des protocoles de transport,

Un seul protocole monolithique
d’authentification et de connexion

Un seul canal de données par session Nombre indéterminé de canaux de

SSH données par session SSH
Vérification cryptographique forte de
Vérification faible de l’intégrité
l’intégrité
– Possibilité de modifier le mot de passe

Les algorithmes de chiffrement, de calcul

de contrôle cryptographique et de
Mêmes algorithmes et clefs utilisés dans
compression sont négociés séparément
les deux sens de la communication
pour chaque sens de communication,
avec des clefs indépendantes
 Schéma de noms des
algorithmes/protocoles extensible,
Encodage fixé interdisant tout ajout de
permettant d’intégrer de nouveaux choix
nouveaux choix d’algorithmes
d’algorithmes tout en préservant
l’interopérabilité

Mise en place d’une clé de session basée sur

Confidentialité de la clé de session transmise
Diffie-Hellman uniquement et donc inutilité
sur le réseau par la clef du serveur
de la clef du serveur SSH

Reconnaissance des certificats de clefs

–
publiques

Méthodes d’authentification des utilisateurs :

Méthodes d’authentification des utilisateurs :  Clef publique (RSA, DAS, OpenPGP)
 Clef publique (RSA), RHostsRSA associée à une machine

 Mot de passe  Mot de passe

 Rhosts (à l’image de rsh dans Unix)  Clef d’hôte (clef asymétrique permettant
d’identifier les hôtes exécutant SSH, ou
 Kerberons (à base de tickets) les instances du serveur SSH de la
machine elle-même)
 Plusieurs méthodes d’authentification
sont configurables pour un même
Une seule forme d’authentification par
utilisateur pour un même accès et le
session
choix est fait lors de la phase
d’initialisation (cf. § 2.2 )

En principe, l’authentification basée sur

L’authentification RhostsRSA est liée à l’hôte est indépendante de l’adresse
l’adresse de l’hôte client, ce qui limite réseau du client et peut ainsi
son utilité fonctionner avec des mandataires, des
clients mobiles, etc.

Renouvellement périodique des clefs de

–
session

Caractéristiques des versions 1 et 2 de SSH

• Ainsi, pour que la couche transport de SSH puisse créer correctement une
session sécurisée entre les deux entités communicantes, de nombreux
éléments sont négociés. En effet, durant l’échange des clefs, le serveur
s’authentifie auprès du client au moyen d’une clef publique RSA ou DSA.
Puisque dans la spécification du protocole SSH, ce dernier ne supporte pas
la distribution des clefs par un tiers de confiance (cas des certificats
X.509), la clef du serveur est inconnue pour le client durant sa première
communication. SSH propose de contourner ce problème en permettant
au client d’accepter la clef du serveur lors de leur première connexion SSH.
Ensuite, lors des connexions suivantes, la clef du serveur peut être vérifiée
au moyen d’une version enregistrée au niveau du client, ce qui permet au
client de s’assurer qu’il communique bien avec le serveur désiré. Ce
mécanisme est l’un des inconvénients majeurs de ce protocole qui le rend
vulnérable à des attaques de type homme du milieu.
• À partir des valeurs publiques DH échangées dans chaque session, les
deux entités génèrent automatiquement une clef de session utilisée avec
des clefs dérivées pour le chiffrement des données. Dès qu’un certain
volume de données est transmis protégé de la même façon à l’aide d’une
clef et d’un algorithme, une nouvelle clé de session doit être mise en
place, ce qui nécessite de nouveaux échanges.
• Le volume exact de données au bout duquel un renouvellement de clés a
lieu est défini dans la norme à 1 giga octet d’échange ou correspond à 1
heure d’échanges sur la session ; tout dépend de la mise en application du
protocole SSH.
• Une fois que la couche 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 pour
l’authentification comme l’utilisation d’une clef asymétrique, ou l’entrée
d’un mot de passe.

• La couche d’authentification SSH (SSH-AUTH)

• Après l’échange des méthodes d’authentification supportées à travers la

couche SSH-TRANS, la couche d’authentification (SSH-AUTH) permet de
certifier l’identité du client auprès du serveur.
• En effet, étant donné que les serveurs peuvent être configurés de façon à
permettre différents types d’authentification, cette couche donne aux
deux parties un niveau de contrôle optimal.
• Le serveur peut décider quelles méthodes d’authentification prendre en
charge en fonction de son modèle de sécurité et le client peut choisir la
méthode d’authentification à utiliser parmi celles qui sont disponibles.
• Les messages échangés par cette couche sont sécurisés par la clef de
chiffrement créée dans la couche SSH-TRANS. Après l’authentification du
client auprès du serveur, de nombreux services peuvent être utilisés de
façon sécurisée, tels qu’une session Shell interactive, des applications X11
et des ports TCP/IP tunnellisés(voir § 3).
• La couche de connexion SSH (SSH-CONN)
Cette couche s’appuie sur la couche d’authentification. Elle offre une
variété riche de services aux clients en se servant de l’unique tunnel fourni
par SSH-TRANS. Ces services comprennent tout ce qu’il faut pour gérer
plusieurs sessions interactives : exécution de programmes à distance
(shell, applications commandes systèmes, etc.), multiplexage de plusieurs
flux (ou canaux), gestion des transferts X11, de port et d’agent. Le
transfert de port TCP permet d’encapsuler des protocoles applicatifs non
sécurisés dans SSH de manière à apporter aux applications des services de
chiffrement et d’intégrité de manière transparente.
Les fonctionnalités des 3 couches de SSH v2 sont résumées dans le
tableau 2.
Dans ce qui suit, nous détaillons la phase d’initialisation du protocole SSH.
 Fonctionnalités des couches SSH v2

Couche Description
— Authentification du serveur, négociation
des algorithmes, mise en place d’une clef
Transport de session, intégrité et confidentialité des
données, compression, identification de
session.
— Authentification du client (clef
Authentification publique, mot de passe, clef d’hôte),
changement du mot de passe.
— Transfert de port TCP et transfert X,
transfert d’agent d’authentification ;
— Gestion des sessions interactives,
Connexion exécution de programmes distants ;
— Contrôle de flux, gestion des terminaux
(modes et tailles des fenêtres) ;
— Compression des données.

Fonctionnalités des couches SSH v2

 2.2 La phase d’initialisation de SSH
• Dans la phase d’initialisation du protocole SSH, de nombreux éléments
importants sont négociés. Dans le cas de l’utilisation du protocole de
communication TCP/IP, la procédure décrite à la figure 2 se déroule de la
façon suivante entre la machine cliente et la machine serveur :
Phase 1 : dès que la connexion est établie (protocole TCP sur le port 22 du
serveur), le client et le serveur échangent en clair le numéro de version du
protocole SSH qu’ils utilisent l’un l’autre. Sitôt ce premier échange
effectué, tous les messages échangés entre le client et le serveur sont
encapsulés dans des paquets SSH possédant tous l’en-tête décrit dans le
tableau 3.
Phase 2 : le serveur commence par envoyer au client, et à travers le
message SSH_MSG_KEXINIT, la liste des méthodes supportées pour la
protection des données (chiffrement, contrôle d’intégrité
cryptographique), la liste des méthodes d’authentification supportées, des
indicateurs d’extension de protocole (par exemple, la méthode de
compression, etc.) et un cookie sur 64 bits que le client devra retourner.
Ce cookie a pour but de protéger le serveur contre les attaques par déni
de service qui visent à inonder le serveur avec des requêtes SSH sans se
soucier des retours effectués par le serveur.
• Le client envoie à son tour la liste des méthodes de protection des
données supportées, la liste des méthodes d’authentification supportées
et une copie du cookie du serveur. Cet échange se termine par l’envoi du
message SSH_MSG_NEWKEYS entre les deux entités communicantes.
• Phase 3 : le client et le serveur envoient respectivement les
SSH_MSG_KEXDH_INIT et SSH_MSG_KEXDH_REPLY pour choisir les
meilleurs algorithmes supportés par les deux. Ils calculent séparément un
identifiant de session à partir des valeurs Diffie-Hellman échangées entre
les deux entités. SSH v2 utilise aussi une méthode d’échange de groupes
DH pour simplifier l’échange DH. Les deux groupes DH définis avec SSH
sont diffie-hellman-group1-sha1 et diffie-hellman-group14-sha1. Le
serveur utilise aussi le message SSH_MSG_KEXDH_REPLY pour envoyer sa
clef et pour signer les valeurs échangées précédemment.
• Phase 4 : le client envoie la demande d’un service à travers le message
SSH_MSG_SERVICE_REQUEST. Par exemple, le service ssh-userauth
correspond à l’activation de la couche SSH-AUTH en vue d’authentifier le
client tandis que ssh-connection à l’activation de SSH-CONN. Le serveur
précise dans ce même message les méthodes d’authentification qu’il
accepte (publickey, password, etc.).
 Format d’un paquet SSH

Packet length Padding length

Payload

Random padding

MAC

Format d’un paquet SSH

• Phases 5 et 7 : à ce stade, la couche SSH-AUTH est maintenant
activée. Le client envoie à travers le message SSH_MSG_USERAUTH_REQU
EST sa méthode d’authentification qui sera acceptée ou pas par le serveur.
Dans la plupart des implémentations SSH et suivant la politique de
sécurité du serveur, le client a le droit à trois tentatives d’authentification
auprès du serveur.

• Phase 6 : si le serveur rejette l’authentification du client, il envoie le

message SSH_MSG_USERAUTH_FAILURE.

• Phase 8 : dans le cas où l’authentification est accordée au client, le serveur

envoie le message SSH_MSG_USERAUTH_SUCCESS pour terminer cette
phase d’initialisation du protocole.
Figure 2 - La phase d’initialisation du protocole SSH v2
 2.3 Les différentes méthodes d’authentification avec SSH

•Trois méthodes d’authentification existent dans la version 2 normalisée à

l’IETF : hostbased, password, et publickey. Le mécanisme d’authentification
basé sur les clefs publiques est le plus fiable, devant l’authentification
classique par couple username/password UNIX. Il utilise une paire de clefs
pour authentifier les entités en communication. SSH assure également le
contrôle d’accès de façon globale au niveau du serveur ou compte par
compte, selon la méthode d’authentification utilisée. En effet, le mécanisme
de contrôle d’accès avec SSH repose sur la définition de listes de contrôle
statique basées sur l’environnement Unix en classant les utilisateurs dans des
groupes suivant leurs privilèges d’accès.

• 2.3.1 L’authentification par mot de passe (password)

•Il s’agit de l’authentification « traditionnelle » où, lors de la connexion et

après avoir décliné son identité, l’utilisateur tape son mot de passe qui sera
transmis de façon protégée au serveur.
•Ce dernier récupère le mot de passe, calcule son empreinte (condensât) et
compare le résultat avec l’empreinte du mot de passe associé à l’utilisateur et
stocké dans sa base de données. Notons que les mots de passe stockés sous
Unix sont chiffrés à l’aide de l’algorithme DES (via la fonction crypt()). D’autres
systèmes utilisent des fonctions de hachage telles que MD5 ou SHA-1.

•Le mécanisme d’authentification par mot de passe (password) est une méthode
d’authentification très simple à mettre en place et qui permet aux utilisateurs
Telnet de migrer vers SSH sans aucun changement au niveau de leur mécanisme
d’authentification sauf que le mot de passe qui transitait en clair avec Telnet est
maintenant encapsulé dans une communication chiffrée, ce qui permet
d’obtenir un meilleur niveau de sécurité de l’authentification. Cependant, cette
méthode d’authentification n’est pas la plus sûre dans SSH. En effet, ce dernier
utilise le même mécanisme de transfert de mot de passe que Telnet qui envoie
un caractère du mot de passe dans chacun des messages. Ceci a augmenté le
nombre d’attaques par analyse de trafic sur cette méthode d’authentification.
2.3.2 L’authentification par clef RSA ou DSA (publickey)

• Le principe de l’authentification à l’aide d’une clef publique repose sur la

cryptographie asymétrique des clefs RSA ou DSA où aucun secret ne
circule sur le réseau. En effet, la clef publique de l’utilisateur doit tout
d’abord être stockée sur le serveur SSH et sa clef privée doit être stockée
sur sa machine de façon sécurisée. Ce système possède un niveau de
sécurité plus élevé que le précédent. Cependant, sa sécurité repose quasi
exclusivement sur un système de confiance « hors ligne ».

• En effet, sur le poste client, l’utilisateur dispose normalement (s’il a généré

les trois types de paires de clefs) de trois fichiers portant un suffixe .pub
dans son répertoire ∼ /.ssh. Il s’agit des clefs publiques associées à ses
clefs privées. Le nom des fichiers fournit une indication sur le type de clef.
id_dsa.pub, id_rsa.pub et identity.pub sont respectivement les clefs
publiques de type dsa et rsa pour SSH2 et rsa1 pour SSH1.
• Pour que le client puisse se connecter en utilisant ses clefs asymétriques, il
doit envoyer à l’administrateur du serveur SSH et d’une manière sûre sa
clef publique. Ce dernier va l’ajouter dans le fichier authorized_keys du
serveur. Ainsi, lors de la connexion, le serveur pourra vérifier l’identité du
client. En quelque sorte, les deux entités doivent vérifier réciproquement
leurs identités en utilisant des moyens de communication plus fiables
qu’Internet : le téléphone, la messagerie électronique sécurisée (mail
sécurisé), etc. Ce problème est détaillé dans le § 4 de ce dossier.

• 2.3.3 L’authentification par hôte (hostbased)

• Il s’agit d’une authentification similaire à celle utilisée par les commandes

et les fichiers tels que /etc/rhosts et ∼ /.rhosts, qui « certifient » les sites
clients en ayant préalablement enregistré leur adresse dans le serveur. En
effet, avec cette méthode d’authentification, quand le client demande une
connexion à un serveur SSH, ce dernier va chercher dans le fichier rhosts
un nom d’hôte qui correspond à l’adresse source de la connexion réseau
du client. S’il trouve un nom d’hôte qui correspond, le serveur vérifie que
le programme demandé par le client est autorisé.
• Ceci, tout simplement en vérifiant si le port en écoute est entre 1 et 1 023.
Ces ports sont considérés comme des ports de confiance puisque seul
l’administrateur de la machine Unix est capable de les activer. Si tout passe
bien, l’authentification se poursuit ; sinon, elle échoue.

• 2.3.4 L’authentification par certificat X.509

• La distribution des clefs publiques ou asymétriques n’est pas toujours

sûre : comment être certain de leur provenance sans avoir utilisé un canal
de transmission fiable ? Supposons qu’Alice veuille transmettre sa clef
publique à Bob. Elle l’envoie en clair sur le réseau. Charlie, sur ce même
réseau, intercepte la clef sans la transmettre, et envoie à la place, sa clef à
Bob. Les messages d’Alice seront alors refusés car la signature sera
mauvaise et les messages envoyés par Charlie seront identifiés comme
provenant d’Alice.
• La seule méthode pour remédier à ce problème est l’utilisation des
certificats X.509 (encadré 4) fondée sur une infrastructure de gestion de
clefs (ou PKI). Un certificat X.509, fourni par une autorité de confiance
(AC), permet à la fois d’authentifier un individu, un serveur, une
entreprise, ou toute autre entité et d’associer l’identité de cette entité
avec sa clef publique. Un certificat X.509 fournit principalement à son
émetteur deux services de sécurité : l’authentification forte et la non
répudiation des transactions ou des données.
• Dans le protocole SSH, même si l’authentification par certificat X.509 des
deux entités communicantes n’est pas encore normalisée au niveau de
l’IETF, il existe des implémentations qui permettent l’utilisation de ces
certificats pour l’authentification dans deux entités SSH.
• Définie par l’IETF, et recommandée par l’ITU depuis 1998, la norme X.509
est l’une des normes les plus utilisées aujourd’hui. La dernière version de
cette norme est la version 3. Un certificat X.509 relie un nom unique
(Distinguished Name – DN) à une clef publique. Un DN est un ensemble de
champs qui identifie de manière unique une entité : c’est le sujet d’un
certificat.
• Le certificat X.509 comprend une partie données (numéro de version,
numéro de série du certificat, période de validité, DN de l’AC, DN du
certificat), une partie extensions indiquant le rôle de ce certificat et une
partie signature (algorithme de chiffrement et signature de l’AC).
 3. Les fonctionnalités offertes par SSH
 
• 3.1 L’accès à distance par le shell SSH

3.2 Le transfert de fichiers par SFTP

3.3 Le tunneling

3.4 La redirection de ports (Port forwarding)

3.5 La redirection de l’authentification (Agent

forwarding)
• Le protocole SSH implémente nativement un certain nombre de fonctions
telles que le shell sur le système distant, le transfert de fichiers et le port
forwarding.

• 3.1 L’accès à distance par le shell SSH

• Le shell SSH (la commande SSH) est une version sécurisée de rsh (et
rlogin). SSH veut dire Secure Shell à l’image de rsh qui veut dire Remote
Shell. Quand rsh permet d’obtenir un shell distant aisément, mais sans
mécanisme d’authentification satisfaisant (du point de vue de la
sécurité), SSH procure le même service de façon sécurisée. Ainsi, pour
utiliser SSH, il suffit d’utiliser la commande ssh à la place des
commandes telnet, rsh et rlogin. Donc, à la place d’utiliser la
commande : %rlogin serveur, il suffit d’utiliser maintenant %ssh serveur.
3.2 Le transfert de fichiers par SFTP
SFTP (Secure File Transfer Protocol) est un sous-protocole séparé qui se
situe au-dessus du protocole SSH. Il est utilisé dans le transfert sécurisé
des fichiers. SFTP a plusieurs avantages par rapport au protocole non
sécurisé FTP. D’abord, SFTP chiffre le couple username/password ainsi
que les données transférées en se basant sur les algorithmes
cryptographiques négociés dans la phase d’initialisation du protocole
SSH. En second lieu, il utilise le même port que le protocole SSH, ce qui
élimine la nécessité d’ouvrir un autre port sur les pare-feux. Ainsi,
l’utilisation de SFTP résout également les problèmes connus dans le
protocole FTP avec la traduction des adresses IP (NAT).

• 3.3 Le tunneling

• En plus de fournir l’équivalent des commandes rcp, rlogin et rsh de

manière chiffrée avec une authentification bien plus sécurisée, les
protocoles SSH permettent la mise en œuvre du tunneling de manière
relativement simple.
• Le tunneling consiste à encapsuler un autre service TCP/IP comme Telnet
ou IMAP, dans une session SSH afin de lui apporter les bénéfices de la
sécurité de SSH (confidentialité, intégrité, authentification, autorisation)
(voir figure 3). Lorsque vous ouvrez une session sur un hôte SSH, vous
pouvez également ouvrir un canal de communication sécurisé pour tous
les autres protocoles. Il est indéniable que la plupart des protocoles
envoient les informations en clair sur le réseau. L’astuce ici est de se
servir du canal ouvert par SSH pour encapsuler les informations en clair
et les faire transiter d’une machine à l’autre. En transférant POP par
exemple, via SSH, toutes les données seront chiffrées et leur intégrité
sera contrôlée. En plus, l’authentification des clients sera assurée d’une
manière sécurisée par SSH.

• SSH reconnaît principalement la redirection de port TCP (cf. § 3.4) et le

transfert des agents SSH (cf. § 3.5) qui permet aussi d’utiliser des clefs
SSH sur des machines distantes. Ces deux fonctionnalités seront décrites
dans les paragraphes suivants.
3.4 La redirection de ports (Port forwarding)

• SSH permet de rediriger n’importe quel flux TCP dans le tunnel de la session SSH.
Cela veut dire que le flux de n’importe quelle application circulant entre les ports
client et serveur habituels, pourra être encapsulé à l’intérieur du tunnel créé par
la session SSH (figure 4). Cette fonctionnalité permet d’établir, entre deux points,
un canal sécurisé par lequel peut transiter n’importe quel type de donnée IP. Le
principe est simple. Prenons l’exemple de la mise en place d’un tunnel IP afin de
sécuriser les connexions entre un client et un serveur POP situé dans l’intranet
d’une entreprise et derrière un serveur SSH. Les étapes sont les suivantes :

• établissement d’une connexion SSH entre le client et le serveur SSH ;

• sur le client : faire pointer le client POP sur le système SSH en local ;
• sur le serveur : transmettre les données arrivant depuis la connexion SSH au
serveur POP.
• Avec un outil de type OpenSSH, cette opération s’effectue via une simple
commande lancée sur le client SSH : # ssh -L 110 : IP serveur POP : 110 <@IP
serveur SSH.
Figure 3 - Tunnels et canaux SSH
Figure 4 - Port forwarding avec SSH
• Ainsi, tout le trafic POP3 entre la machine cliente et le serveur SSH sera
alors sécurisé par le tunnel SSH, mais ce qui transite entre le serveur POP
et le serveur SSH ne le sera pas. En effet, il s’agit habituellement d’un gain
de sécurité, puisque la communication entre ces deux dernières machines
se fait habituellement sur un réseau privé.

• 3.5 La redirection de l’authentification (Agent

forwarding)

• L’agent SSH est un mécanisme d’authentification auprès de multiples

serveurs SSH qui reconnaissent la clef privée d’un client sans devoir
retaper à chaque fois sur sa machine sa « passphrase* ».
• Nota :

• * La « passphrase » est un mot de passe sous forme de phrase et qui sert à

protéger la clef privée asymétrique de l’utilisateur.
• En effet, un agent SSH est un programme, qui s’appelle ssh-agent, qui
garde les clefs privées en mémoire et qui fournit les services
d’authentification aux clients SSH. Cette méthode permet à un utilisateur
d’introduire sa passphrase lors de la première connexion à un serveur SSH.
L’ouverture d’une session sécurisée avec un nouveau serveur SSH se fait
de manière transparente pour l’utilisateur.
• Si l’utilisateur souhaite, par exemple, faire une copie de fichier (scp) entre
deux serveurs distants (cf. figure 5), SSH offre une fonctionnalité qui
s’appelle Agent Forwarding et qui permet à des machines distantes
d’accéder à l’agent local de l’utilisateur pour pouvoir récupérer ces droits
d’accès et d’exécution à ces programmes distants (dans ce cas, c’est le
programme scp). La clef privée de l’utilisateur reste toujours en local.
L’agent SSH ne fait que relayer les requêtes d’authentification vers l’hôte
local pour identifier l’utilisateur. Le serveur distant se comporte comme un
deuxième programme ssh-agent. Ainsi, le client ne retape pas son mot de
passe une deuxième fois puisque les serveurs vont communiquer
directement avec l’agent du client. Notons qu’en activant cette
fonctionnalité, l’utilisateur peut se connecter à un réseau SSH, éliminant
les problèmes de compromission de sa clef privée. En effet, sans activation
de l’agent SSH, chaque serveur SSH dans la chaîne d’authentification de
l’utilisateur (sauf le dernier) doit stocker une copie de la clef privée.
Figure 5 - Authentification par agent et exécution de la commande
scp entre deux serveurs SSH
• L’utilisation de l’agent SSH est plus sûre que la mise en œuvre des clefs
sans protection par « passphrase », mais cela ne semble pourtant pas
suffisant. Par mesure de sécurité et en fonction de l’endroit d’où
l’utilisateur se connecte, il est préférable de prendre la peine de saisir
manuellement les phrases de passe à chaque authentification. En effet,
comme les connexions d’agent transférées sont implémentées sous la
forme de sockets de domaine Unix, un attaquant qui arrive à lire/écrire sur
cette socket, sera capable d’utiliser et compromettre les clefs privées des
utilisateurs.

• 4. SSH vs les autres solutions VPN

•  Le rôle d’un réseau privé virtuel (VPN, Virtual Private Network) est
d’étendre un réseau privé en exploitant un réseau public, par exemple de
manière sécurisée. Un VPN permet alors de relier plusieurs entités ou sites
et d’intégrer à un réseau privé des utilisateurs itinérants. La plupart des
VPN se base sur l’utilisation de tunnels, qui repose sur l’utilisation d’un
réseau public, où les échanges sont sécurisés. Le mode de fonctionnement
est d’encapsuler les données à transporter dans les paquets du protocole
réalisant le tunnel.
• Au cours de la dernière décennie, un certain nombre de protocoles de
sécurité a été développé et accepté par les communautés des
développeurs et des usagers d’Internet. Nous citons par exemple le
protocole PPTP, développé par Microsoft et qui installe, via PPP, un tunnel
sécurisé entre des postes nomades (fonctionnant principalement sur
Windows) et l’Intranet. Cependant, pour un autre usage visant à relier
plusieurs intranets par un réseau sécurisé, c’est le protocole IPSec qui
s’impose. Le grand intérêt d’IPSec par rapport à d’autres techniques, est
qu’il s’agit d’une méthode standard (facultative en IPv4 et obligatoire en
IPv6), mise au point dans le but précis d’interconnecter des LANs. En effet,
un VPN IPSec apporte de multiples éléments assurant la sécurité des
réseaux. Il réduit considérablement les risques d’intrusions depuis
l’extérieur sous forme d’usurpation d’adresse IP et d’écoute passive. De
plus, un VPN IPSec protège un intranet des virus tels que les worms,
spécifiquement conçus pour se propager à grande vitesse sur Internet. Il
reste la solution la plus déployée pour relier les réseaux des entreprises à
travers un réseau non sécurisé comme Internet. Reste à préciser que IPsec
est un système assez complexe, qui dépend de nombreux facteurs
interdépendants.
• En particulier, la redondance des fonctionnalités offertes par les sous-
protocoles d’IPSec, le rattachement de ce protocole aux constructeurs des
équipements réseaux et des systèmes d’exploitations, et les problèmes liés
à l’ambiguïté dans la mise en place des différentes normes IPSec.
• SSH permet d’établir des canaux sécurisés dans un réseau ouvert et
assure, entre autres, des VPNs beaucoup plus faciles à déployer que le
protocole IPSec. Ce dernier nécessite des ajouts au système d’exploitation
des machines situées aux deux extrémités de la connexion, et également,
il nécessite la modification de la politique de sécurité des équipements
réseau intermédiaires afin de permettre la négociation des flux IKE sur le
port 500 de UDP, ainsi que les flux des sous-protocoles IPSec, ESP
(Encapsulating Security Payload) et AH (Authentification Header), sur les
ports 50 et 51 respectivement. Par ailleurs, SSH utilise la technique de
SOCKS intégrée dans la plupart des équipements réseaux.
• Cependant, un concurrent de même niveau que SSH vient de s’imposer.
C’est la solution VPN SSL. SSL est un protocole de sécurité du même
niveau que SSH. Même si ce protocole n’offre pas nativement une solution
VPN, plusieurs constructeurs se sont lancés au cours de ces cinq dernières
années dans le développement d’une gamme de produits VPN SSL.
• Ces produits permettent principalement de palier les difficultés
rencontrées avec IPSec et les accès distants (dues notamment à la
traduction d’adresse et au filtrage d’applications dans le réseau distant –
cf. § 5.4). Par ailleurs, même si VPN SSH pouvait être un vrai concurrent à
VPN SSL, le grand avantage de ce dernier vient du fait qu’il est déjà intégré
dans la plupart des navigateurs Web. Ainsi, les utilisateurs nomades
peuvent se connecter à travers le protocole SSH depuis n’importe quel
ordinateur (PDA, Cybercafé, réseau protégé par un pare-feu laissant
passer les flux http, etc.) sans modification à apporter sur le poste distant.
• Le tableau 4 résume les caractéristiques des technologies VPN décrites ci-
dessus.
5. Les limites du protocole SSH
•  

•5.1 La première authentification non sécurisée du

client avec le serveur SSH

5.2 Les attaques sur le mot de passe

5.3 L’authentification non sûre par « hôte de

confiance »

5.4 SSH et la traduction des adresses réseau (NAT)

• SSH est capable de contourner de nombreuses menaces de sécurité liées
au réseau. Cependant, il est vulnérable aux attaques par déni de service,
héritant ainsi des faiblesses de TCP/IP sur lequel il repose.
• Si le protocole TCP/IP résiste aux problèmes de congestion et de ruptures
de liens IP, il n’a pas été cependant conçu pour résister à des attaques
d’injections de faux paquets dans le réseau. SSH, lui, ne fournit aucune
protection contre les attaques qui brisent l’établissement des connexions
TCP. En revanche, les mécanismes de chiffrement et d’authentification
dans ce protocole sont efficaces contre les attaques détournant ou
altérant des données TCP/IP, car SSH les détecte, mais elles briseront
également sa session. Dans ce qui suit, nous détaillons les principaux
inconvénients de SSH.
 Caractéristiques des trois principales technologies
VPN : IPSec, SSH et SSL
SSH IPSec SSL
Normalisation 2006 à l’IETF. 1998 à l’IETF. 1999 à l’IETF.
Interconnexions
Interconnexions
entre des
entre des Interconnexions
utilisateurs
Principale utilisateurs des sites
nomades et le site
utilisation nomades et le site d’entreprises via
de leur entreprise
de leur entreprise Internet.
via une session
via Internet.
Web.
Sécurité
Sécurisation des Sécurisation des
transparente pour
Niveau OSI applications au- applications au-
les applications
dessus de TCP. dessus de TCP.
au-dessus d’IP.
  Confidentialité.

 Intégrité.
 Confidentialité.
 Authentification.
 Intégrité.
Non rejeu des paquets (grâce
aux cookies, et aux numéros  Authentification.
aléatoires utilisés dans la
phase d’initialisation du Non rejeu des paquets (grâce
protocole (SSH-CONN), les aux cookies, et aux numéros  Confidentialité.
données envoyées ne peuvent aléatoires utilisés dans la
 Intégrité.
pas être rejouées après un phase d’initialisation du
certain temps) protocole (IKE), les données  Authentification.
envoyées ne peuvent pas être
 Protection d’identité du rejouées après un certain Non rejeu des paquets (grâce
Service de sécurité
client SSH (les méthodes temps). aux numéros aléatoires
d’authentification du utilisés dans la phase
client SSH, par  Protection d’identité de handshake du protocole, les
username/mot de passe, l’émetteur et du données envoyées ne peuvent
clef asymétrique ou par récepteur IPSec (les pas être rejouées après un
certificat X.509 sont méthodes certain temps)
chiffrées avec la clef de d’authentification, par
chiffrement SSH). clef partagée, clef
asymétrique ou
 Autorisation, (c.à.d, certificat X.509, sont
contrôle d’accès aux protégées par la clef de
comptes), tunnel chiffrement IPSec).
sécurisé, port
forwarding, service de
SSO (Single Sign On).
 SSL utilise une
Dépend du méthode de
protocole externe chiffrement
Gestion des clefs à
IKE (basé sur DH asymétrique (RSA
Gestion des clefs travers un échange
ou sur un ou DSA) ou des
Diffie-Hellman.
chiffrement clefs DH pour la
asymétrique). création d’un secret
partagé.

Méthodes
Username/mot de Clef partagée, clef
d’authentification Clef partagée ,
passe, clef asymétrique,
définies dans les certificat X.509.
asymétrique. certificat X.509.
normes

Par paquet (niveau

réseau), lié aux
Impossible après Impossible après
Mécanisme de politiques de sécurité
l’ouverture d’un l’ouverture d’une
filtrage définies par les
tunnel SSH. session SSL.
administrateurs pour
IPSec.
  Comme pour SSL,
plus adapté pour
 Plus adapté pour
l’accès sur demande
l’accès sur demande
des utilisateurs.
 Plus adapté pour des utilisateurs.
 Sécurise tout le l’accès à un
 Sécurise tout le
trafic entre le client ensemble défini des
trafic du navigateur
et le serveur SSH. utilisateurs.
au serveur principal.
 Contrôle d’accès au  Accès total pour les
 Accès « oui non » au
niveau serveur SSH clients VPN à un
Contrôle d’accès niveau d’application,
basé sur un fichier segment d’un réseau.
basé sur une liste
de configuration
 Solution idéale pour d’accès statiques
statique.
la sécurisation au (ACL).
 Solution idéale pour niveau réseau.
 Solution limitée aux
les environnements
 Problème de applications qui
Unix. Problème de
complexité. supportent une
gestion des clefs chez
interface Web ou qui
les utilisateurs et un
intègrent SSL/TLS.
manque d’interface
complète.
 5.1 La première authentification non sécurisée du
client avec le serveur SSH
•Puisque SSH n’utilise pas de tiers de confiance pour distribuer les clefs publiques, la
première fois qu’un client SSH se connecte à une nouvelle machine distante, il
effectue un travail supplémentaire en vérifiant lui-même la clef publique du serveur,
soit en comparant le hachage, soit en contactant l’administrateur du serveur distant.

•Une fausse acceptation de la clef publique envoyée par le serveur SSH peut laisser
une personne malveillante détourner le trafic SSH en envoyant une fausse clef lors
de la première connexion au serveur SSH.

•Ce problème peut aussi se poser si le client utilise une clef asymétrique pour
s’authentifier. En effet, le serveur doit disposer de l’ensemble des clefs publiques de
ses clients. L’ensemble des clefs publiques des clients pouvant se connecter au
serveur doit être envoyé préalablement au serveur. Dans le cas d’utilisation d’un
serveur OpenSSH, les clefs publiques des utilisateurs sont toutes ajoutées dans le
fichier ∼ /.ssh/authorized_keys du serveur.
5.2 Les attaques sur le mot de passe
•En encapsulant les données applicatives dans des paquets SSH, ce dernier
ajoute du bourrage à chaque paquet (bourrage de taille fixe pour SSH v1,
bourrage de taille variable en fonction des méthodes de chiffrement par
blocs pour SSH v2) ; SSH chiffre les données et les envoie en clair dans le
champ plaintextlength. Ainsi, un attaquant passif, espionnant le trafic SSH,
est capable de détecter la taille des données envoyées sur le réseau et ainsi
de mener à bien des attaques par analyse de trafic.

•Comme dans Telnet, les caractères formant le mot de passe des clients SSH
sont envoyés directement dans des paquets IP séparés. Une personne
malveillante qui observe ces paquets peut conclure non seulement le
nombre de caractères formant le mot de passe mais elle peut aussi, à travers
des méthodes markoviennes s’appuyant sur le temps et le délai nécessaire
par le client pour introduire son mot de passe, estimer les différents
caractères du mot de passe.
 5.3 L’authentification non sûre par « hôte de
confiance »
• Par définition, l’authentification par hôte de confiance renvoie aux
méthodes d’authentification Rhosts, RhostsRSA de SSH-1 et hôte de SSH-2.
Plutôt que de demander au client de prouver son identité à tous les hôtes
qu’il visite, l’authentification par hôte de confiance établit des relations de
confiance entre les machines. Même si l’authentification par hôte de
confiance est pratique pour les utilisateurs et les administrateurs (car elle
permet de mettre en place une authentification automatique entre des
hôtes), cette technique dépend lourdement d’une administration correcte
et de la sécurité des hôtes concernés. En effet, si un seul de ces hôtes est
compromis, un attaquant pourra accéder automatiquement à tous les
comptes des autres hôtes.

• 5.4 SSH et la traduction des adresses réseau (NAT)

Un autre problème de SSH est lié à la sécurisation des applications
interactives, comme le protocole FTP, qui traversent des réseaux masqués
par une passerelle NAT.
• Nous rappelons que la traduction des adresses réseau ou NAT (Network
Address Translation) consiste à connecter deux réseaux par une passerelle
réécrivant les adresses source et destination des paquets lorsqu’ils la
traversent. L’avantage du NAT est qu’il permet de partager un nombre
limité d’adresses Internet routables entre un grand nombre de machines
utilisant des adresses privées.
• Avec SSH, il est impossible de se connecter avec un tunnel SSH sécurisé
vers des serveurs FTP situés derrière une passerelle NAT.
• Tout d’abord, nous allons présenter les deux moyens par lesquels FTP
réalise le transfert de fichier. Le premier mode de transfert de fichier dans
FTP est le mode actif où l’utilisateur va essayer de copier un fichier d’un
serveur distant vers sa machine locale. Dans ce cas, l’utilisateur va choisir
une socket TCP locale disponible et il va l’envoyer avec la commande
« PORT adresse IP Source, port » au serveur distant afin que ce dernier
puisse commencer le transfert de fichier.
• Avec le mode passif de FTP, c’est le client qui est à l’origine de la connexion
vers le serveur. Plus précisément, au lieu d’attendre sur une socket locale
et d’envoyer une commande PORT au serveur, l’utilisateur envoie une
commande « PASV adresse IP Source, port ».
• Le serveur choisit alors une socket de son côté sur laquelle écouter et
l’indique au client dans sa réponse à PASV.
• Avec SSH, le mode passif de FTP ne fonctionne pas, car le serveur FTP
fournit son adresse interne au client et cette adresse ne peut être atteinte
par le client. En plus, l’utilisation du mode actif n’est pas simple puisque
derrière le NAT, on trouve des machines clientes où la configuration des
NAT et pare-feux laisse les connexions en mode passif seulement. Une
solution à ce problème est que la passerelle NAT réécrive
automatiquement le trafic du contrôle FTP en transit afin de prendre en
compte la traduction d’adresses. Cette solution est impossible avec SSH
qui protège en intégrité et en confidentialité les données et empêche par
la suite toute modification intermédiaire (par la passerelle NAT ou autre).

• 6. Les principales distributions de SSH

 
• Il existe plusieurs distributions du protocole SSH dont les deux plus
importantes sont OpenSSH livrées avec la plupart des versions Linux et
Tectia de la société SSH inc.
• OpenSSH est une implémentation libre et sous licence GNU du protocole
SSH. Ce projet a été pris en charge au départ par le projet OpenBSD : Il
s’agissait d’une reprise de la version 1.2.12 du protocole SSH (la dernière
version libre de Tau Ylönen), intégrée au système d’exploitation OpenBSD
2.6. De nombreux développeurs se sont alors intégrés au projet pour
rajouter des fonctionnalités, améliorer la portabilité du code et corriger
certains bugs protocolaires. Depuis mai 2000, OpenSSH supporte les deux
versions du protocole SSH (v1.5 et 2.0).
• La dernière version est la 4.3. Elle peut être installée sur la plupart des OS
et architectures. Pour cela, OpenSSH est pour le moment, le produit le
plus utilisé et référencé par les grandes entreprises pour la fourniture
d’une solution SSH. Les nouvelles versions de ce logiciel intègrent
également des fonctionnalités supplémentaires telles qu’un système de
contre-mesures permettant de déjouer les attaques basées sur la mesure
du temps séparant les paquets contenant les mots de passe de l’utilisateur
pour tenter de déterminer les saisies effectuées au clavier. Des patchs
peuvent aussi être ajoutés pour fournir des méthodes d’authentification
forte à SSH. Nous citons en particulier le patch de T. Petrov qui permet
l’intégration d’un système d’authentification forte fondé sur les certificats
X.509, aussi bien pour le client que le serveur.
• Cependant, il existe dans le marché d’autres solutions qui commercialisent
SSH. La société SSH Inc., principal éditeur du protocole SSH, développe et
commercialise la version 2.x du protocole SSH. Cette version, connue sous
le nom de « Tectia client/server solution » est actuellement la première
solution commerciale dans le domaine du marché. Elle intègre la plupart
des solutions d’authentification forte de type RSA Secure ID, PKI, RACF IBM
et autres. L’avantage de ce produit réside dans le fait que la société SSH
inc. est le principal contributeur à la normalisation du protocole SSH au
sein de l’IETF. Ainsi, l’outil intègre, en avant premier, toutes les nouvelles
normes et propositions de normalisation liées à ce protocole.
• Les références que nous citons dans le tableau 5 sont des produits utilisés
principalement dans le domaine industriel et jugés suffisamment stables
et fonctionnels.
 Quelques produits SSH
Société/Orga Méthodes
nisation – d’authentific
Produit Plateforme Protocole Usages
Pays – Site ation
officiel supportées
Proposé en
standard dans
la plupart des Mot de passe,
distributions clef publique,
Unix. Il Kerberos
existe aussi OpenSSH
Versions 1 et (le patch de
OpenSSH dans www.openssh [Patrov] Usage libre
2
l’environnem .org permet
ent Cygwin l’authentifica
pour tion à base de
Windows PKI)
(http://www.c
ygwin.com)
 Attachmate
WRQ
Mot de
F-Secure Windows et Versions 1 et (États-Unis) Version
passe, clef
SSH Unix 2 http://www.a publique commerciale
ttachmatewr
q.com/

Vandyke
Secure CRT
Windows et Versions 1 et (États-Unis) Mot de passe, Version
(version 5.1.
Unix 2 www.vandyk clef publique commerciale
1)
e.com

WinSSHD
WinSSHD
Versions 1 et (États-Unis) Mot de passe, Version
(version 4.15 Windows
2 www.winssh clef publique commerciale
a)
d.com
 SSF – SSF est une
(Centre version
IN2P3 – gratuite.
SSF (version CNRS) – Mot de
Windows et C’est une
francisée de Version 1 France passe, clef
Unix adaptation à
SSH) publique
http://polyw la législation
ww.in2p3.fr/ française de
grpinfo/ ssf/ SSH

SSH Secure ID,

Tectia
Windows et Versions 1 et corporation – PKI, Versions
Solution Finland
Unix 2 Kerberos, commerciales
(version 5)
www.ssh.org Radius
 7. L’avenir de l’exploitation du protocole SSH
•  Jusqu’à présent, la meilleure utilisation du protocole SSH se faisait dans le
cadre de la sécurisation des connexions à distance vers les serveurs
d’applications ou les machines réseaux telles que les routeurs et les points
d’accès. Cependant, la plupart de ces équipements réseaux proposent
actuellement un mécanisme d’accès simple basé sur une interface Web
non sécurisée. D’où la nécessité de trouver très rapidement une solution
de sécurité simple à déployer pour des utilisateurs non forcément experts
dans la configuration de ces équipements réseaux.
• Bien que SSH possède l’avantage d’être déployé dans la plupart des
équipements réseaux, les grands fournisseurs de ces équipements, tels
que CISCO, SIEMENS, ont préféré choisir le protocole SSL/TLS avec une
session HTTPS pour l’établissement des sessions sécurisées vers les
serveurs de configuration Web embarqués dans ces équipements.
Cependant, le standard SSL/TLS n’intègre qu’une solution
d’authentification basée sur le déploiement d’une PKI avec autorité(s) de
certification.
• Dans des environnements fermés, l’utilisation de l’authentification à base
de certificats et de PKIs est indésirable à cause du temps de calcul
cryptographique et du coût élevé de la gestion des certificats. D’où la
nécessité d’intégrer un mécanisme d’authentification simple basé sur les
clefs partagées dans SSL/TLS.
• Dans cet objectif, le groupe de travail TLS à l’IETF s’est focalisé sur la
standardisation d’une nouvelle proposition qui intègre un mécanisme
d’authentification fondé sur les clefs partagées et le chiffrement
asymétrique. La clef partagée est utilisée pour l’authentification mutuelle
alors que le chiffrement asymétrique est utilisé pour générer une clef pour
chaque session.
• Parmi plusieurs propositions exposées à l’IETF, le groupe de travail IETF
TLS a choisi les deux drafts IETF de TLS-PSK et Nokia-Siemens comme base
du standard TLS-PSK qui intègre un mécanisme d’authentification basé
sur les clefs partagées et le chiffrement asymétrique. TLS-PSK assure
plusieurs services additionnels par rapport aux standards TLS et SSH. Ces
services deviennent de plus en plus indispensables, non seulement pour
les réseaux mobiles, mais aussi pour les fixes.
• Parmi ces services, nous citons la protection de l’identité des utilisateurs
et la protection contre les attaques rétroactives sur la confidentialité des
données (PFS – Perfect Forward Secrecy). La protection contre les attaques
passives et par dictionnaire est aussi améliorée.

• 8.Conclusion
•  Le protocole SSH constitue une approche puissante et pratique pour
protéger les communications sur un réseau d’ordinateurs. À travers son
mécanisme d’authentification, SSH permet d’effectuer dans un tunnel
sécurisé, des connexions à distance, des transferts de fichiers, et d’autres
fonctionnalités importantes telles que le tunneling et la redirection de
port. Ces deux derniers ont fait de SSH le protocole de sécurité le plus
transparent pour les applications. En effet, une application non sécurisée
peut bénéficier de l’ensemble des services de sécurité de SSH sans aucun
changement/ajout dans son code ou noyau. C’est SSH tout seul qui va
maintenir la sécurité des données applicatives, l’authentification des
entités communicantes, le chiffrement et le contrôle d’intégrité des
données.
• Cependant, même si SSH a pu contourner de nombreuses menaces à la
sécurité liées au réseau, il reste rattaché, dans sa spécification, à une
conception logicielle plus qu’à un vrai protocole de sécurité. Même si SSH,
dans sa version 2, est devenu plus modulaire et extensible, nous pouvons
remarquer que les fonctionnalités de chaque sous-protocole dépendent
fortement des autres sous-protocoles.
• Par exemple, le service d’authentification entre deux entités est divisé
entre la couche d’authentification et la couche de transport. Ceci rend ce
protocole non applicable aux nouveaux environnements sans fils et ainsi
incapable de satisfaire les nouveaux besoins des applications et des
utilisateurs.