Le SSH, pour Secure SHell permet de répondre à la principale problématique posée par la sécurité des informations : la confidentialité.

Présentation générale

En effet, avec ce protocole, il est possible de chiffrer des donnĂ©es par un systĂšme d'Ă©change de clĂ©s privĂ©es et publiques. Ces donnĂ©es transitent dans un tunnel, un canal sĂ©curisĂ© oĂč il est impossible de savoir ce qu’il se passe Ă  l’intĂ©rieur.

logo ssh

Le SSH a Ă©tĂ© mis au point par un Finlandais, Tatu Ylönen. La version 1 du SSH qui Ă©tĂ© proposĂ©e dĂšs 1995 Ă©tait une alternative aux protocoles comme Telnet, rsh, ou encore rlogin. Toutefois, cette version 1 du protocole avait une vulnĂ©rabilitĂ© qui permettait Ă  un hacker d’insĂ©rer des donnĂ©es dans le flux sĂ©curisé  Informations complĂ©mentaires Ă  cette adresse.

La version 2 est l’évolution majeure (en plus d’avoir de nombreux correctifs de sĂ©curitĂ©) de la premiĂšre monture du SSH ; Cette version inaugure le transfert de fichiers de façon sĂ©curisĂ©e avec le protocole FTP. On parle alors de SFTP, pour "Secure File Transfert Protocol". Aujourd’hui encore, c’est cette version 2 qui est utilisĂ©e quotidiennement.

Fonctionnement du protocole SSH

Un client (humain ou machine), appelĂ© "pair" peut ouvrir une session interactive sur une machine distante, lui permettant d’envoyer des commandes et/ou des fichiers de maniĂšre sĂ©curisĂ©e. Pour que cette connexion soit Ă©tablie entre les hĂŽtes, une authentification mutuelle est nĂ©cessaire pour s’assurer que les machines communiquent entre elles, soit bien les machines "rĂ©elles". L’identitĂ© des pairs est vĂ©rifiĂ©e avant d'entamer le moindre transfert de donnĂ©e. L’usurpation d’identitĂ© est limitĂ©e avec ce protocole, ni mĂȘme l’écoute du rĂ©seau par un capteur de paquets ou un analyseur de trames
 En effet, mĂȘme si un attaquant capture les paquets de ce flux, il ne pourra les dĂ©chiffrer sans avoir les paires de clĂ©s.

ssh diagram

La mise en place d’un canal sĂ©curisĂ©

NĂ©gociation de l’algorithme de chiffrement

Pour permettre la communication entre les deux machines, il faut d’abord commencer une phase de nĂ©gociation entre les pairs, Ă  savoir le client et le destinataire, pour s’accorder sur l’algorithme de chiffrement Ă  utiliser. Le protocole SSH est prĂ©vu pour pouvoir fonctionner avec de nombreux algorithmes de chiffrement, notamment Ă  l'aide du paquet openssl.

Établissement de la connexion

Une fois l’algorithme de chiffrement trouvĂ© en accord entre les pairs, le serveur envoie sa clĂ© publique d’hĂŽte (Host Key) au client. Le client gĂ©nĂšre alors une clĂ© de session d’un nombre de bits prĂ©-dĂ©finis (128, 256, 512, 1024, 2048, 4096, 8192). Plus le nombre de bits est important, plus la clĂ© de session sera difficile Ă  casser ; elle sera toutefois plus longue Ă  dĂ©chiffrer pour les deux parties. Le dĂ©chiffrement s'effectue grĂące Ă  la clĂ© publique reçue du serveur.

Le client envoie cette clĂ© gĂ©nĂ©rĂ©e au serveur en plus de l’algorithme de chiffrement utilisĂ©. Pour rappel, cet algorithme de chiffrement est connu des deux parties communicantes.

Le serveur reçoit la clé publique du client et la déchiffre grùce à sa clé privée. Si les clés sont reconnues, le serveur envoie un message de confirmation chiffré avec la clé publique de son client.

Une fois l’échange des clĂ©s terminĂ© et positif entre le client et le serveur, la communication est alors chiffrĂ©e grĂące Ă  l’algorithme sĂ©lectionnĂ© par les pairs et en utilisant les clĂ©s publiques de chacune des parties.

L’authentification dite "simple"

Lorsque la connexion est Ă©tablie entre les parties, le client doit s’identifier sur le serveur. La principale mĂ©thode d’authentification est la suivante :

  • Le client envoie un nom d’utilisateur et le mot de passe associĂ© lors de l’établissement de la connexion ;
  • Le serveur vĂ©rifie si l’utilisateur en question peut obtenir un accĂšs Ă  la machine, si le mot de passe fourni est valide.
    Si les tests sont validĂ©s, l’authentification est alors rĂ©ussie. Sinon, l’accĂšs au serveur est refusĂ© et la connexion est immĂ©diatement interrompue.

L’authentification par clĂ©s

Une autre mĂ©thode existe pour s’authentifier sans utiliser de mot de passe. Elle s’appuie sur la paire de clĂ© privĂ©e/publique des pairs concernĂ©s. Pour rappel, ces clĂ©s ont Ă©tĂ© gĂ©nĂ©rĂ©es avant la connexion (on parle d’une paire de clĂ©s, comprenant une clĂ© publique et une clĂ© privĂ©e) :

  • Le serveur crĂ©e un "challenge" avec sa clĂ© publique pour tester le client.
  • Le client reçoit ce challenge. Son but : Le dĂ©chiffrer avec sa clĂ© privĂ©e (client).
  • Le client renvoie sa rĂ©ponse lorsqu’il a rĂ©ussi Ă  dĂ©chiffrer le challenge
  • Le serveur autorisera l’accĂšs au client si et seulement si la rĂ©ponse reçue est positive.

Conclusion

Le protocole SSH est un moyen fiable pour protĂ©ger l’accĂšs Ă  ses serveurs, en plus d'ĂȘtre relativement simple Ă  mettre en place. GrĂące Ă  ce protocole, il devient difficile d’usurper l’identitĂ© d’une machine ou d’une personne grĂące au systĂšme de clĂ© publique et privĂ©e uniques gĂ©nĂ©rĂ©e alĂ©atoirement (en plus d’ĂȘtre chiffrĂ©e).

Ainsi, pour Ă©tablir une connexion entre un client et un serveur via SSH, l’authentification (et donc l’accĂšs) ne sera possible que lorsque la vĂ©rification des clĂ©s entre les parties sera en adĂ©quation. Dans le cas contraire, la connexion est coupĂ©e et l'authentification rejetĂ©e.

Partager l'article