(Le titre initial de l'article «Algorithme de fonctionnement du protocole SSH» a été modifié selon les recommandations de Vindicar , Karroplan et d'autres membres de l'habro-communauté)En lisant périodiquement des articles sur SSH, j'ai remarqué que leurs auteurs n'avaient parfois aucune idée du fonctionnement de ce protocole. Dans la plupart des cas, ils se limitent à considérer le sujet de la génération de clés et à décrire les options des commandes principales. Même les administrateurs système expérimentés sont souvent absurdes lorsqu'ils discutent des problèmes SSH, en émettant des opus avec style: les données transmises sont chiffrées avec la clé SSH publique du client et déchiffrées avec la clé privée, ou: l'algorithme RSA est utilisé pour chiffrer les données pendant la transmission.
Je vais essayer d'apporter un peu de clarté au fonctionnement du protocole SSH, et en même temps considérer le rôle de l'algorithme RSA et des clés d'autorisation utilisateur ...
L'algorithme du protocole SSH peut être divisé en trois niveaux, chacun situé au-dessus du précédent: transport (ouverture d'un canal sécurisé), authentification, connexion. Par souci d'intégrité de l'image, j'ajouterai également un niveau de configuration de connexion réseau, bien qu'officiellement ce niveau soit inférieur à SSH.
1. Établissez une connexion TCP
Je ne m'attarderai pas sur le principe de la pile TCP / IP, car ce sujet est bien documenté dans Runet. Si nécessaire, vous pouvez facilement trouver des informations.
À ce stade, le client se connecte au serveur sur le port TCP spécifié dans l'option Port (par défaut: 22) dans le fichier de configuration du serveur / etc / ssh / sshd_config.
2. Ouverture d'un canal sécurisé
2.1 Échange d'identitéUne fois la connexion TCP établie, le client et le serveur (ci-après dénommés les parties) échangent des versions du protocole SSH et d'autres données de prise en charge nécessaires pour déterminer la compatibilité du protocole et sélectionner des algorithmes de fonctionnement.
2.2 Choix d'algorithmes: échange de clés, chiffrement, compression, etc.Lorsque vous travaillez avec SSH, un certain nombre d'algorithmes sont utilisés, certains d'entre eux sont utilisés pour le cryptage, le second pour l'échange de clés, le troisième pour la compression des données transmises, etc. À cette étape, les parties s'envoient mutuellement des listes d'algorithmes pris en charge, les algorithmes en haut de chaque liste ayant la priorité la plus élevée. Ensuite, les algorithmes dans les listes obtenues sont comparés aux algorithmes disponibles dans le système, et le premier correspondant dans chaque liste est sélectionné.
Une liste des algorithmes d'échange de clés côté client disponibles (utilisés pour obtenir une clé de session) peut être consultée avec la commande:
ssh -Q kex
Liste des algorithmes symétriques disponibles dans le système (utilisés pour le cryptage des canaux):
ssh -Q cipher
La liste des types de clés pour l'autorisation chez le client:
ssh -Q key-cert
Mis à jour par la remarque onix74 :Toutes les commandes utilisées dans la publication sont pertinentes pour OpenSSH version 7.6 d'Ubuntu 18.04 LTS.
2.3 Obtention d'une clé de chiffrement de sessionLe processus d'obtention d'une clé de session peut différer selon la version de l'algorithme, mais en termes généraux, cela se résume à ce qui suit:
Une clé de session est créée exclusivement pour la durée de vie du canal et est détruite lorsque la connexion est fermée.
3. Authentification client
Et seulement maintenant, lorsque le client et le serveur ont établi un canal pour la transmission de données cryptées, ils peuvent s'authentifier avec un mot de passe ou des clés.
De manière générale, l'authentification par clé se déroule comme suit:
- Le client envoie au serveur un nom d'utilisateur (nom d'utilisateur) et sa clé publique.
- Le serveur recherche dans le fichier /home/username/.ssh/authorized_keys la clé publique envoyée par le client. Si la clé publique est trouvée, le serveur génère un nombre aléatoire et le chiffre avec la clé publique du client, après quoi le résultat est envoyé au client.
- Le client déchiffre le message avec sa clé privée et envoie le résultat au serveur.
- Le serveur vérifie le résultat pour une correspondance avec le numéro qu'il a chiffré à l'origine avec la clé publique du client, et s'il correspond, il considère que l'authentification a réussi.
4. Niveau de connexion
Après avoir effectué toutes les procédures ci-dessus, l'utilisateur a la possibilité d'envoyer des commandes au serveur ou de copier des fichiers.
À ce niveau, il est fourni: multiplication des canaux (possibilité de faire fonctionner plusieurs canaux sur un serveur en les combinant en un seul canal), tunneling, etc.
De la théorie à la pratique
Eh bien, maintenant, je pense que les lecteurs ont une question tout à fait logique: pourquoi avez-vous besoin de connaître tous ces détails du protocole SSH, si pour le travail quotidien, il y a suffisamment de connaissances sur les commandes de création de clés (ssh-keygen), l'ouverture d'une session de terminal (ssh), le transfert de fichiers ( scp)?
En guise de réponse, nous pouvons rappeler le sujet de la modification du port SSH standard en un autre, qui devient constamment la cause de holivar sur Habr ...
Dans ma propre pratique, je ne me souviens pas d'un seul serveur regardant le réseau externe qui ne serait pas exploité quotidiennement sur le port 22. Dans une situation où SSH fonctionne pour vous sur un port standard (et n'est protégé par rien), même si l'authentification par clés uniquement et aucune supposition de mot de passe ne fait peur, alors en raison de demandes constamment en suspens de clients malhonnêtes, le serveur est toujours obligé de faire beaucoup de travail inutile: établir une connexion TCP, sélectionner des algorithmes, générer une clé de session, envoyer des demandes d'authentification, écrire un fichier journal.
Dans une situation où il n'y a rien sur le 22e port, ou si le port est protégé à l'aide d'iptables (ou de modules complémentaires comme fail2ban), l'attaquant abandonnera au stade de l'établissement d'une connexion TCP.
Le plus intéressant décrit ressemble à un tableau *
| La configuration | Hacking Chance | Pertes dues aux inondations ** |
|---|
22 ports
autorisation de mot de passe,
sans protection | haut | haut |
22 ports
autorisation de clé,
sans protection | moyenne *** | haut |
22 ports
autorisation de clé,
protection basée sur la restriction des tentatives d'autorisation infructueuses | faible | moyen **** |
Port non standard,
autorisation de mot de passe,
sans protection | haut | faible |
Port non standard,
autorisation de clé,
sans protection | moyenne *** | faible |
Port non standard,
autorisation de clé,
protection basée sur la restriction des tentatives d'autorisation infructueuses | faible | faible |
* - les valeurs des paramètres (élevée, moyenne, faible) sont de nature relative et ne servent qu'à comparer les indicateurs.
** - cela signifie la consommation de ressources du serveur (processeur, disque, canal réseau, etc.) pour traiter une avalanche de requêtes qui vont généralement au port 22.
*** - Le piratage si les clés RSA sont utilisées pour l'autorisation est très difficile, mais un nombre illimité de tentatives d'autorisation rend cela possible.
**** - le nombre de tentatives d'autorisation est limité, mais le serveur doit encore les traiter à partir d'un grand nombre d'intrus.
Matériel supplémentaire