La sécurité joue toujours un rôle majeur sur Internet : c’est pourquoi le protocole de sécurité SSH est fermement intégré dans la pile de pro­to­coles TCP/IP. Le protocole SSH permet aux uti­li­sa­teurs d’établir une connexion sécurisée entre deux or­di­na­teurs. Le protocole réseau est utilisé depuis 1995 et a été depuis lors révisé et actualisé à plusieurs reprises. Nous ex­pli­quons les termes les plus im­por­tants en lien avec le protocole SSH et comment fonc­tionne ce chif­fre­ment.

Fait

Une interface système (shell en anglais) est la partie du système d’ex­ploi­ta­tion avec laquelle les uti­li­sa­teurs peuvent accéder à l’or­di­na­teur. On entend gé­né­ra­le­ment par-là une interface en ligne de commande textuelle (ou invite de commande, terminal ou console), mais l’interface uti­li­sa­teur graphique fait également partie du « shell ». La procédure d’éta­blis­se­ment d’une connexion est appelée Secure Shell car le protocole établit une connexion sécurisée avec l’interface système (shell) d’un autre or­di­na­teur.

Pourquoi avez-vous besoin de SSH ?

SSH permet à deux or­di­na­teurs d’établir une connexion directe et sécurisée au sein d’un réseau po­ten­tiel­le­ment non sécurisé, tel qu’Internet. Ceci est né­ces­saire pour que des tiers ne puissent pas accéder au flux de données et que les données sensibles ne tombent entre de mauvaises mains. Même avant Secure Shell, il était possible d’établir des con­nexions directes entre deux or­di­na­teurs, mais les ap­pli­ca­tions cor­res­pon­dantes telles que Telnet, Remote Shell ou rlogin n’étaient pas toujours sûres. SSH chiffre la connexion entre deux or­di­na­teurs et permet d’utiliser un deuxième or­di­na­teur à partir d’un seul.

SSH fournit non seulement une connexion chiffrée, mais garantit également que seules des con­nexions sont établies entre les or­di­na­teurs désignés (de sorte qu’aucune attaque de l’homme du milieu ne soit possible) et que les données cor­res­pon­dantes ne peuvent être ma­ni­pu­lées sur le chemin du des­ti­na­taire. À l’origine, l’accès à distance de l’or­di­na­teur se faisait toujours via les lignes de commande. Elles sont utilisées pour envoyer des commandes à l’appareil distant. Main­te­nant, il est également possible d’utiliser Virtual Network Computing (VNC) pour dupliquer une interface uti­li­sa­teur graphique (qui n’est pas toujours dis­po­nible sur les serveurs) sur votre propre or­di­na­teur et ainsi contrôler l’autre or­di­na­teur.

SSH possède de nom­breuses ap­pli­ca­tions possibles dif­fé­rentes :

  • Gestion des serveurs auxquels il n’est pas possible d’accéder lo­ca­le­ment
  • Transfert de fichiers sécurisé
  • Création sécurisée de sau­ve­gardes
  • Connexion entre deux or­di­na­teurs utilisant le chif­fre­ment de bout en bout
  • Té­lé­main­te­nance d’autres or­di­na­teurs

Le dé­ve­lop­pe­ment de SSH a également influencé d’autres pro­to­coles. Par exemple, le protocole FTP non sécurisé, avec lequel il est possible de té­lé­char­ger des fichiers sur un serveur et de les té­lé­char­ger à nouveau à partir de là, a été développé dans le protocole SFTP (SSH File Transfer Protocol).

Un avantage de SSH est que le protocole fonc­tionne sur tous les systèmes d’ex­ploi­ta­tion courants. Comme il s’agissait à l’origine d’une ap­pli­ca­tion Unix, il est également im­plé­menté par défaut sur toutes les dis­tri­bu­tions Linux et sur macOS. Mais SSH peut aussi être utilisé sous Windows si vous installez un programme approprié.

SSH vs. OpenSSH

Secure Shell a été créé à l’origine en 1995 en tant que projet open source. La même année, le dé­ve­lop­peur Tatu Ylönen a fondé une société pour dé­ve­lop­per le protocole. Le projet ini­tia­le­ment open source s’est donc de plus en plus trans­formé en un logiciel pro­prié­taire. Cependant, la com­mu­nauté réseau n’a pas accepté cela sim­ple­ment et a développé en réaction un fork libre basé sur le protocole SSH-1 : OpenSSH. Cependant, comme SSH Com­mu­ni­ca­tion Security continue également à tra­vail­ler sur Secure Shell, deux pro­to­coles con­cur­rents coexis­tent désormais. D’une part, il y a le protocole pro­prié­taire SSH-2 (un dé­ve­lop­pe­ment com­plé­men­taire, car les failles de sécurité sont devenues connues dans SSH-1) et d’autre part, il existe OpenSSH.

OpenSSH et le SSH « com­mer­cial » sont à peu près équi­va­lents en fonc­tion­na­lité et en portée. La dif­fé­rence concerne prin­ci­pa­le­ment les coûts, mais aussi le support technique. Si vous optez pour le produit SSH Com­mu­ni­ca­tion Security, vous bé­né­fi­ciez également d’une as­sis­tance 24h/24 et 7j/7. Cela peut être par­ti­cu­liè­re­ment utile pour les grandes en­tre­prises dont les res­pon­sables in­for­ma­tiques changent souvent. OpenSSH, d’autre part, a l’avantage de la com­mu­nauté open source, ce qui signifie que le projet est cons­tam­ment développé par de nombreux par­ti­ci­pants.

Comment fonc­tionne SSH ? Ex­pli­ca­tion

Secure Shell utilise plusieurs tech­niques de chif­fre­ment et d’au­then­ti­fi­ca­tion. D’une part, cela garantit que les flux de données ne peuvent être ni lus ni manipulés. Par contre, seuls les par­ti­ci­pants autorisés peuvent se contacter entre eux.

Au­then­ti­fi­ca­tion

Dans un premier temps, le serveur SSH et le client s’au­then­ti­fient mu­tuel­le­ment. Le serveur envoie un cer­ti­fi­cat au client pour vérifier qu’il s’agit bien du bon serveur. Ce n’est que lors du premier contact qu’un tiers risque de commuter entre les deux par­ti­ci­pants et d’in­ter­cep­ter ainsi la connexion. Comme le cer­ti­fi­cat lui-même est également chiffré, il ne peut pas être imité. Une fois que le client sait quel est le bon cer­ti­fi­cat, personne d’autre ne peut prétendre contacter le serveur approprié.

Après l’au­then­ti­fi­ca­tion du serveur, le client doit également s’iden­ti­fier au serveur en tant qu’uti­li­sa­teur autorisé. Ceci ou la valeur de hachage chiffrée de celui-ci est stockée sur le serveur. Toutefois, cela signifie également que les uti­li­sa­teurs doivent entrer leur mot de passe chaque fois qu’ils se con­nec­tent à un serveur différent au cours de la même session. Par con­sé­quent, il existe une autre pos­si­bi­lité d’au­then­ti­fi­ca­tion côté client, l’uti­li­sa­tion de l’au­then­ti­fi­ca­tion par paire de clefs privée et publique.

La clef privée est créée in­di­vi­duel­le­ment pour votre propre or­di­na­teur et sécurisée avec une phrase de chif­fre­ment qui devrait être plus longue qu’un mot de passe classique. La clef privée est stockée ex­clu­si­ve­ment sur votre propre or­di­na­teur et reste secrète à tout moment. Si vous voulez établir une connexion SSH, entrez d’abord la phrase de chif­fre­ment et ouvrez l’accès à la clef privée.

Sur le serveur (ainsi que sur le client lui-même) il y a aussi des clefs publiques. Le serveur crée un problème cryp­to­gra­phique avec sa clef publique et l’envoie au client. Ce dernier déchiffre à son tour le problème avec sa propre clef privée, renvoie la solution et informe le serveur qu’il est autorisé à établir une connexion légitime.

Au cours d’une session, vous n’avez besoin d’entrer la phrase de chif­fre­ment qu’une seule fois pour vous connecter à un nombre quel­conque de serveurs. A la fin de la session, les uti­li­sa­teurs se dé­con­nec­tent de leur machine locale pour s’assurer qu’aucun tiers ayant un accès physique à la machine locale ne peut se connecter au serveur.

Chif­fre­ment

Après une au­then­ti­fi­ca­tion mutuelle, les deux par­ti­ci­pants à la com­mu­ni­ca­tion éta­blis­sent une connexion chiffrée. Pour ce faire, une clef est générée pour la session, et expire à la fin de la session. Il ne faut pas confondre cela avec les paires de clefs publiques/privées, qui ne sont utilisées que pour l’échange de clés. La clé utilisée pour le chif­fre­ment sy­mé­trique n’est valable que pour cette seule session. Le client et le serveur ont la même clef, donc tous les messages échangés peuvent être chiffrés et dé­chif­frés. Le client et le serveur créent la clé si­mul­ta­né­ment, mais in­dé­pen­dam­ment l’un de l'autre. Dans l’al­go­rithme d’échange de clés, les deux parties utilisent certaines in­for­ma­tions publiques et secrètes pour créer la clé.

Une autre forme de chif­fre­ment a lieu avec SSH par la fonction de hachage. Un hachage est une forme de signature des données trans­mises. À l’aide d’un al­go­rithme, un hachage unique est généré à partir des données. Si les données sont ma­ni­pu­lées, la valeur de hachage change également au­to­ma­ti­que­ment. Cela permet au des­ti­na­taire de voir si les données ont été modifiées par des tiers en cours de route. Les valeurs de hachage sont conçues de telle sorte qu’elles ne peuvent pas être sim­ple­ment simulées. Idéa­le­ment, il n’est jamais possible de créer deux trans­mis­sions dif­fé­rentes.

Ports SSH

Les ports TCP sont des terminaux qui ouvrent des serveurs et des clients pour permettre la com­mu­ni­ca­tion. Comme pour un port, les par­te­naires de com­mu­ni­ca­tion reçoivent et envoient les paquets de données via ce port. TCP a un espace d’adressage de 16 bits et donc 65535 ports sont dis­po­nibles. Cependant, l’Internet Assigned Numbers Authority (IANA) a attribué quelques ports (exac­te­ment 1024) pour certaines ap­pli­ca­tions : le port SSH également. Par défaut, toutes les con­nexions SSH fonc­tion­nent ainsi sur le port 22.

Remarque

Comme le port utilisé pour les con­nexions SSH est gé­né­ra­le­ment connu et ap­pa­rem­ment utilisé pour trans­mettre des données sensibles, le port SSH est une cible de choix pour les cy­ber­cri­mi­nels. Par con­sé­quent, certains uti­li­sa­teurs pensent qu’il est logique de déplacer le port SSH. Toutefois, cela n’offre qu’une pro­tec­tion à court terme. Avec un scanner de ports, il est possible de trouver tous les ports utilisés par une machine.

SSH permet également la re­di­rec­tion de port (port for­war­ding) : le port SSH d’un client ou d’un serveur est utilisé par un autre abonné dans un réseau local pour établir une connexion sécurisée sur Internet. Pour cela, les par­ti­ci­pants créent un tunnel : les données sont reçues via le port 22 puis trans­mises au client dans le réseau local.

Clients SSH

Le client SSH est gé­né­ra­le­ment votre propre or­di­na­teur avec lequel vous voulez établir une connexion au serveur. Pour ce faire, vous pouvez ou devez (selon le système d’ex­ploi­ta­tion) installer un logiciel séparé qui établit une connexion SSH. Ces pro­grammes sont aussi appelés clients SSH. SSH Com­mu­ni­ca­tion Security provient de Tectia SSH qui contient aussi un serveur logiciel. Il existe également de nom­breuses al­ter­na­tives gratuites, telles que le logiciel open source PuTTy pour Windows et Linux ou lsh qui fonc­tionne sur tous les systèmes d’ex­ploi­ta­tion sous Unix.

Conseil

Certains pro­grammes four­nis­sent aux uti­li­sa­teurs une interface graphique qui simplifie la con­fi­gu­ra­tion et le dé­ploie­ment de SSH. En principe, Secure Shell peut également être exécuté à partir de la ligne de commande sous macOS et autres systèmes d’ex­ploi­ta­tion de type Unix, même sans ins­tal­la­tion sup­plé­men­taire.

Serveur SSH

Le serveur SSH est le pendant du client. Ici aussi, le terme est en même temps utilisé pour le logiciel. Une grande partie du logiciel pour les clients fonc­tionne également sur des serveurs. En outre, il existe également des logiciels conçus ex­clu­si­ve­ment pour les serveurs SSH. Il est courant de démarrer SSH sur les serveurs au démarrage. Ceci garantit que vous pouvez accéder au serveur depuis l’extérieur via SSH à tout moment.

Il n’est d’ailleurs pas né­ces­saire que le serveur SSH soit en fait un serveur au sens strict, situé dans un centre de données à distance. Les uti­li­sa­teurs peuvent également installer un serveur SSH sur leur propre or­di­na­teur à la maison pour bé­né­fi­cier des avantages du transfert de port, par exemple.

Aller au menu principal