Forum Linux.général ssh et chiffrement symétrique

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
-1
13
déc.
2016

bonjour à tous

en lisant la doc sur ssh: http://formation-debian.via.ecp.fr/ssh.html

je m'interroge sur le passage ci dessous:

Nous allons suivre par étapes l'établissement d'une connexion SSH :

Le serveur envoie sa clef publique au client. Celui-ci vérifie qu'il s'agit bien de la clef du serveur, s'il l'a déjà reçue lors d'une connexion précédente.

Le client génère une clef secrète et l'envoie au serveur, en chiffrant l'échange avec la clef publique du serveur (chiffrement asymétrique). Le serveur déchiffre cette clef secrète en utilisant sa clé privée, ce qui prouve qu'il est bien le vrai serveur.

Pour le prouver au client, il chiffre un message standard avec la clef secrète et l'envoie au client. Si le client retrouve le message standard en utilisant la clef secrète, il a la preuve que le serveur est bien le vrai serveur.

Une fois la clef secrète échangée, le client et le serveur peuvent alors établir un canal sécurisé grâce à la clef secrète commune (chiffrement symétrique).

Une fois que le canal sécurisé est en place, le client va pouvoir envoyer au serveur le login et le mot de passe de l'utilisateur pour vérification. La canal sécurisé reste en place jusqu'à ce que l'utilisateur se déconnecte.

"Le client génère une clef secrète et l'envoie au serveur"
comment le client génère t il la clé symétrique,a quel moment et est ce toujours la même clé ?

  • # Éléments de réponse

    Posté par  (site web personnel) . Évalué à 5.

    en lisant la doc sur ssh:

    C'est gentil, mais ça, ce n'est pas la doc sur SSH, c'est une documentation sur SSH, à laquelle j'ai participé d'ailleurs.

    Si tu veux plus de détails, c'est la RFC qui définit le protocole SSH qu'il va falloir aller voir. Mais de mémoire, il me semble qu'une clef symétrique est simplement une chaîne d'octets aléatoires d'une certaine longueur. Donc, pour répondre à tes questions :

    comment le client génère t il la clé symétrique

    En prenant des octets dans /dev/random je pense.

    a quel moment

    Au début, vu que cette clef symétrique va être utilisée dans toute la suite, dans la mesure où elle est au cœur de l'initialisation d'un canal sécurisé, qui est l'objet de la connexion SSH.

    et est ce toujours la même clé ?

    D'une session sur l'autre, non, elle est générée pour chaque connexion SSH. En revanche, pendant que tu es connecté par SSH quelque part, elle reste la même. À moins qu'il n'y ait un mécanisme de renégociation, je n'ai pas vérifié.

    • [^] # Re: Éléments de réponse

      Posté par  . Évalué à -10.

      merci tanguy pour ces quelques rapides réponses
      ce serait bien d'ajouter ces détails dans la documentation debian

      de plus:
      où est défini la longueur de la clé symétrique dans mon système,est ce paramètrable ?

    • [^] # Re: Éléments de réponse

      Posté par  . Évalué à 6.

      c'est une documentation sur SSH, à laquelle j'ai participé d'ailleurs.

      Il me semble que cette partie n’est pas correcte :

      Le client génère une clef secrète et l'envoie au serveur, en chiffrant l'échange avec la clef publique du serveur […] Une fois la clef secrète échangée, le client et le serveur peuvent alors établir un canal sécurisé grâce à la clef secrète commune

      Cela sous-entend que la paire de clefs asymétriques du serveur est utilisé à la fois pour authentifier le serveur auprès du client, et pour chiffrer la clef de session (symétrique).

      Je ne crois pas que ça se passe ainsi. La paire de clefs asymétriques est utilisé pour l’authentification uniquement. Une fois le serveur authentifié, le serveur et le client procèdent à un échange Diffie-Hellman pour obtenir tous les deux la clef de session symétrique ; cet échange n’implique pas la paire de clefs asymétriques du serveur.

      C’est un détail qui a son importance, car cela implique qu’une éventuelle compromission ultérieure de la clef privée du serveur ne permettra pas de déchiffrer les clefs de session et donc de revenir déchiffrer le traffic enregistré (alors que ce serait possible si les clefs de session étaient directement chiffrées avec la clef publique du serveur).

      En revanche, pendant que tu es connecté par SSH quelque part, elle reste la même. À moins qu'il n'y ait un mécanisme de renégociation, je n'ai pas vérifié.

      Oui, un tel mécanisme existe. Le RFC 4253 suggère une telle re-négociation chaque fois qu’un giga-octets de données a été transféré, ou après chaque heure écoulée. Dans OpenSSH, ça se configure avec l’option RekeyLimit.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.