Comment fonctionne le protocole Secure Shell (SSH) ?

Longtemps cantonné à l’administration système, le protocole Secure Shell (SSH) s’impose aujourd’hui comme un standard incontournable pour le chiffrement des connexions, le transfert de fichiers sécurisé et l’automatisation des tâches critiques. Pourtant, dans un contexte d’entreprise notamment, il reste parfois sous-exploité ou mal configuré, faute de compréhension fine de ses mécanismes d’authentification et de ses options de sécurisation. Découvrez tout ce qu’il faut savoir sur le fonctionnement technique du protocole SSH, les différentes méthodes pour établir des connexions sécurisées, et les bonnes pratiques cyber pour gérer efficacement les clefs SSH dans un environnement professionnel.

Qu'est-ce que le protocole SSH?

Définition du protocole Secure Shell

Le protocole SSH (Secure Shell) est une norme de communication sécurisée, conçue à la fin des années 1990 pour remplacer les protocoles obsolètes tels que Telnet et Rlogin. Ces derniers transmettaient les informations, dont les identifiants d’authentification, en clair sur le réseau, exposant les administrateurs systèmes à des risques de compromission importants. En réponse, le protocole SSH a été développé pour garantir la confidentialité, l’intégrité et l’authentification des connexions à distance.

D’un point de vue technique, SSH repose sur un mécanisme de chiffrement asymétrique. Lorsqu’une connexion SSH est initiée, une phase de négociation permet d’établir un canal chiffré entre le client et le serveur. Celle-ci permet de créer un canal chiffré, sécurisé dès les premiers échanges. Pour cela, les deux parties utilisent un algorithme d’échange de clefs (comme Diffie-Hellman ou Curve25519), qui leur permet de générer une clef de session partagée sans jamais l’envoyer sur le réseau. 

En parallèle, ils se mettent d’accord sur les algorithmes à utiliser pour cette session : le chiffrement des données (ciphers), la vérification d’intégrité (MAC : Message Authentication Code), et la méthode d’échange de clefs (KEX : Key Exchange). Ces éléments garantissent respectivement la confidentialité, l’intégrité et la sécurité de l’échange initial.

Une fois ce tunnel sécurisé établi, toutes les données échangées sont chiffrées et protégées contre les interceptions ou les modifications. L’authentification peut alors avoir lieu, soit par mot de passe, soit — plus couramment aujourd’hui — par clefs SSH. Ce mécanisme permet également au client de vérifier l’identité du serveur distant, grâce à sa clef publique connue, ce qui réduit fortement les risques d’attaques de type man-in-the-middle, par exemple.

Avantages et cas d'usage du SSH en entreprise

Dans un environnement professionnel, le protocole SSH constitue un outil central pour la sécurisation des accès à distance, recommandé par l’ANSSI¹. Il permet aux administrateurs système, développeurs et équipes DevOps de se connecter en toute sécurité à des serveurs distants pour effectuer des opérations sensibles. On parle alors de connexion SSH pour qualifier cette session sécurisée, établie via la ligne de commande ou des interfaces graphiques spécialisées.

Mais SSH ne se limite pas à l’administration distante ; il est également utilisé pour le transfert de fichiers sécurisé, à travers des protocoles dérivés comme SFTP ou SCP. Ces usages répondent à une nécessité forte : protéger les données en transit contre tout accès non autorisé.

Comparé à des solutions historiques comme Telnet ou FTP, SSH apporte un niveau de sécurité nettement plus élevé. Il est aujourd’hui largement adopté dans les environnements conformes aux standards réglementaires comme le RGPD ou la norme ISO 27001. Par ailleurs, l’usage du protocole SSH participe à la réduction de la surface d’exposition de l’entreprise, notamment en remplaçant des accès non chiffrés par des tunnels sécurisés.

SSH TCP ou UDP : quel protocole réseau utilise SSH ?

Le protocole SSH fonctionne exclusivement au-dessus du protocole TCP (Transmission Control Protocol). Ce choix n’est pas anodin : TCP est un protocole orienté connexion, garantissant la fiabilité et l’intégrité des paquets transmis. Cela signifie que chaque segment de données est accusé de réception, et que l’ordre des paquets est maintenu.

Dans le contexte de SSH, cette fiabilité est indispensable. La moindre corruption de données pourrait compromettre la session, voire engendrer des risques de sécurité.

À l’inverse, le protocole UDP (User Datagram Protocol) ne garantit ni l’ordre ni la livraison des paquets. C’est pourquoi SSH ne fonctionne pas en UDP : ce protocole ne permettrait pas d’assurer le niveau de sécurité attendu dans des contextes d’administration système ou de transfert de données sensibles.

Comment se connecter en SSH ?

Connexion SSH classique : la méthode complète

Établir une connexion SSH suppose de disposer d’un client compatible. Sur les systèmes Unix, Linux ou macOS, le client OpenSSH est généralement intégré par défaut. Côté Windows, des solutions comme PuTTY, SecureCRT ou Termius sont couramment utilisées, en fonction des besoins et des politiques d’administration système en place.

La connexion SSH s’effectue via la ligne de commande, selon une syntaxe simple.

Exemple typique avec OpenSSH :

ssh utilisateur@adresse_ip -p 2222

• ssh : commande de base permettant d’initier une connexion sécurisée.
• utilisateur : identifiant possédant des droits d’accès SSH sur la machine cible.
• adresse_ip : adresse IP ou nom d’hôte du serveur distant.
• -p 2222 : option facultative spécifiant un port personnalisé (le port par défaut de SSH est 22).

Si aucune clef SSH n’est précisée, le client utilise la clef privée par défaut, généralement stockée dans ~/.ssh/id_rsa, ou propose une authentification par mot de passe. Pour une configuration plus maîtrisée, il est possible de désigner explicitement une clef privée via l’option -i :

ssh -i ~/.ssh/maclef utilisateur@adresse_ip

Ce mécanisme permet de choisir précisément quelle identité utiliser pour chaque session SSH, renforçant ainsi le contrôle des accès.

Authentification SSH : choisir entre mots de passe et clefs SSH

Par défaut, une connexion SSH peut être protégée par un mot de passe. Cette méthode, bien que simple à mettre en œuvre, présente des risques de sécurité importants : mots de passe faibles, fuites d’identifiants, attaques par dictionnaire ou par force brute... De plus, elle complique l’audit des accès, notamment en cas de partages non contrôlés.

L’authentification par clef SSH offre une alternative bien plus sécurisée. Elle repose sur une paire de clefs : la clef publique, installée sur le serveur, et la clef privée, conservée localement par l’utilisateur. Lors de la connexion, le serveur s’assure que la clef privée correspond à une clef publique autorisée.

Ce mécanisme renforce considérablement la sécurité des échanges : aucune donnée sensible ne transite, la robustesse cryptographique empêche les attaques par force brute, et l’usage d’une passphrase permet de protéger la clef privée en cas de compromission. C’est aujourd’hui la méthode recommandée dans tout environnement professionnel exposé.

Comment générer et gérer une clef SSH sécurisée ?

La génération d’une clef SSH repose sur un outil standard : ssh-keygen, disponible par défaut sur la majorité des systèmes Unix/Linux et via les packages OpenSSH sur Windows. Avant toute création, il est utile de connaître les différences entre les principaux algorithmes disponibles.

• RSA : historiquement le plus répandu, compatible avec tous les serveurs SSH, mais nécessite une longueur de clef élevée (4096 bits) pour un bon niveau de sécurité.
  
  
• ECDSA : basé sur les courbes elliptiques, plus rapide que RSA à taille équivalente, mais dépend de l’implémentation du serveur côté chiffrement elliptique.
  
  
• Ed25519 : algorithme moderne, rapide, sécurisé et recommandé par défaut. Il utilise une taille de clef fixe, sans compromis sur la performance ni la robustesse.

Pour générer une paire de clefs SSH, il s’agit d’exécuter la commande suivante :

ssh-keygen -t rsa -b 4096

• -t rsa : précise que l’on souhaite générer une clef de type RSA.
• -b 4096 : indique la taille de la clef, ici renforcée à 4096 bit
  
  

Pour les autres algorithmes, la syntaxe varie légèrement :

• ECDSA : ssh-keygen -t ecdsa -b 521
• Ed25519 : ssh-keygen -t ed25519 (l’option -b est inutile ici : la taille de clef est prédéfinie et optimisée.)

À l’issue de la génération, deux fichiers sont produits :

• La clef privée, (~/.ssh/id_rsa, id_ecdsa ou id_ed25519), qui doit rester strictement confidentielle,
• La clef publique, (fichier .pub),  que l’on peut copier sur le serveur distant (dans le fichier ~/.ssh/authorized_keys).
  
  

Néanmoins, il faut garder à l’esprit qu’une mauvaise gouvernance des clefs SSH peut exposer l’infrastructure à des accès fantômes ou à des élévations de privilèges non détectées. À l’inverse, une gestion rigoureuse permet de réduire fortement les risques d’exploitation liés aux accès à distance.

Pour garantir la sécurité des connexions SSH sur le long terme, plusieurs précautions doivent donc être prises :

• Stockage sécurisé : la clef privée doit être conservée dans un répertoire protégé (~/.ssh/), avec des permissions strictes (chmod 600), et idéalement protégée par une passphrase. (voir recommandations de l’ANSSI relatives aux mots de passe en 2025)
  
  
• Gestion centralisée : l’utilisation d’un gestionnaire de clefs permet de superviser les usages, d’automatiser la distribution et la révocation, et d'assurer une traçabilité complète dans une logique de Privileged Access Management (PAM).
  
  
• Cycle de vie maîtrisé : il est recommandé de révoquer les clefs inutilisées, de renouveler périodiquement les clefs actives, et d’auditer régulièrement les accès établis via SSH.

LockPass pour générer, sécuriser et lancer des connexions

Sécurisation avancée des accès SSH avec LockPass

La sécurisation des accès distants par connexion SSH repose en grande partie sur la bonne gestion des clefs privées. Or, dans de nombreuses entreprises, celles-ci sont encore stockées localement, de manière non centralisée, voire partagées entre plusieurs utilisateurs, rendant toute traçabilité impossible. C’est précisément sur ce point que LockPass apporte une réponse structurée.

Le coffre-fort de mots de passe LockPass permet de centraliser l’ensemble des clefs SSH utilisées au sein de l’entreprise, tout en maintenant un haut niveau de sécurité. Les clefs privées ne résident plus sur les postes utilisateurs, mais sont gérées via un coffre-fort numérique sécurisé. L’accès aux serveurs SSH se fait de manière contrôlée, selon des règles de permissions et de privilèges définies par rôle ou par équipe.

Cette approche offre plusieurs avantages au niveau de la sécurité, mais également côté gestion pour les DSI :

• Auditabilité complète : chaque connexion SSH est associée à un utilisateur identifié, avec un historique consultable à tout moment.
  
  
• Révocation rapide : en cas de départ d’un collaborateur ou de suspicion de compromission, les droits d’accès peuvent être désactivés immédiatement, sans dépendre d’une intervention sur les serveurs.
  
  
• Gestion granulaire des accès : les droits sont attribués selon le principe du moindre privilège (PoLP), avec une délégation fine adaptée aux besoins opérationnels, sans exposition excessive. Cette logique s’inscrit pleinement dans une approche de Privileged Access Management (PAM), où les accès à privilèges sont centralisés, contrôlés, et tracés dans le temps. En intégrant les accès SSH dans un dispositif PAM via LockPass, les équipes IT peuvent donc mieux encadrer l’usage des comptes sensibles, limiter les mouvements latéraux en cas d’intrusion, et répondre aux exigences de conformité de manière plus structurée.

Par ailleurs, en structurant la gestion des accès SSH de cette manière, LockPass facilite aussi la conformité aux exigences réglementaires (ISO 27001², DORA…), notamment en matière de contrôle des accès à privilèges et de journalisation.

Automatisation et gestion facilitée des sessions SSH via LockPass

LockPass ne se contente pas de sécuriser les clefs : il simplifie aussi l’usage quotidien des connexions SSH grâce à un mécanisme d’accès aveugle. Concrètement, un collaborateur peut établir une session SSH vers un serveur autorisé sans jamais voir ni manipuler la clef privée. L’authentification est entièrement gérée par la plateforme, ce qui supprime le risque de fuite ou de vol de fichiers de clefs sur les postes utilisateurs.

Cette approche réduit considérablement la surface d’attaque au niveau des terminaux, tout en améliorant la fluidité opérationnelle pour les équipes techniques. Chaque session est tracée, horodatée, et peut être analysée a posteriori en cas d’incident. Ce niveau de surveillance en temps réel permet d’assurer un contrôle continu sur les usages des accès à privilèges.

Pour renforcer encore cette capacité de contrôle, LockPass s’intègre avec les principaux outils de cybersécurité utilisés en entreprise. Ces interconnexions permettent de replacer les connexions SSH dans une stratégie cyber globale, à la fois cohérente et évolutive :

• SIEM : pour centraliser les journaux d’activité SSH, croiser les données avec d’autres événements de sécurité, et déclencher automatiquement des alertes en cas d’anomalie (tentatives de connexions répétées, connexions hors plage horaire, volumétrie inhabituelle).
  
  
• IAM : pour aligner la gestion des clefs SSH avec la gouvernance des identités numériques. Les droits d’accès sont attribués dynamiquement, selon les rôles, les équipes ou les projets, avec un suivi complet du cycle de vie.
  
  
• MFA : pour ajouter une étape d’authentification multifacteurs avant l’ouverture d’une session SSH, y compris dans le cadre d’un accès aveugle. L’utilisateur est ainsi validé sur plusieurs facteurs, même sans manipulation de clef.
  
  

Pour découvrir comment cette logique s’applique concrètement au sein de LockPass, consultez notre article dédié :

 Le connecteur SSH – nouvelle fonctionnalité LockPass.

Vous l’aurez compris, dans un contexte où les accès à privilèges figurent parmi les principales cibles des attaquants, cette capacité à superviser, bloquer et corréler les connexions SSH avec les autres événements de sécurité constitue un atout déterminant pour la résilience des systèmes d’information.

À lire aussi

Articles recommandés pour booster votre cybersécurité

Cybersécurité

ANSSI : 3 étapes pour piloter la remédiation cyber

Actualités LockSelf

Le connecteur SSH : nouvelle fonctionnalité LockPass à venir

Cybersécurité

PCA : 5 étapes pour le mettre en place + exemple !

Sources : 

1 https://cyber.gouv.fr/publications/usage-securise-dopenssh