OpenSSH 5.6 est disponible

Posté par (page perso) . Modéré par Xavier Teyssier.
Tags :
31
26
déc.
2010
OpenBSD
OpenSSH 5.6 est sorti ce 23 août 2010 et personne n'en avait encore parlé. Le logiciel, fortement lié au projet OpenBSD permet d'offrir un accès à distance à un autre système de manière sécurisée. L'utilisation la plus connue est l'utilisation d'un shell sur l'autre système via la commande ssh, mais il est aussi possible de transférer des fichiers via scp, un équivalent à cp, et sftp.

Parmi les nouveautés, on trouve :
  • L'ajout d'une option ControlPersist qui permet de lancer un ssh multiplex master lors de la première connexion qui reste actif aussi longtemps que désiré. Cela permet d'éviter une nouvelle ouverture de session à chaque connexion, ce qui peut faire sensiblement gagner du temps lors de l'utilisation de tunnels par exemple ;

  • Un nouveau format de certificat de clef a été introduit, notamment, afin d'améliorer la sécurité. L'ancien format introduit avec la version 5.4 sera encore pris en charge pendant au moins un an après la sortie de la version 5.6, avant de devenir obsolète et d'être retiré ;

  • La gestion par ssh-keygen de la signature des certificats en utilisant une clef stockée dans un jeton PKCS#11.
  • # Nouveau format de certificat de clef

    Posté par . Évalué à 2.

    Le nouveau format de certificat de clef c'est pour remplacer celui qui s'affichait en une sorte de ASCI art et qui permettait un rendu visuel ?

    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Nouveau format de certificat de clef

      Posté par (page perso) . Évalué à 8.

      L'ASCII art c'est juste une représentation visuelle de la fingerprint qui est censée être plus reconnaissable qu'une suite de chiffres en hexadecimal. C'est indépendant du format de la clé pour autant que je sache (enfin, si la clé change, la représentation va changer).

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # OpenSSL

    Posté par . Évalué à 6.

    et pour rappel, OpenSSL (rien à voir avec OpenBSD mais utilisé par OpenSSH) avait été mis à jour le 29 Mar 2010 en v1.0.0

    http://alpha.linuxfr.org/users/lapinflemard/journaux/openssl(...)

    Avec notamment l'inclusion dans le trunk des patch pour la RFC3161 (timestamp authority, vous envoyé un hash de vos données à un serveur de "confiance" il vous renvoi une version signé avec la date, utilisé par exemple pour prouver le dépôt d'offre à la bonne date sur les marchés publics, et il me semble les courriers avec accusé de réception envoyé via le site de la poste)
    • [^] # Re: OpenSSL

      Posté par . Évalué à 4.

      Il y a quelques temps, je me demandais s'il y avait des notaires ou autres qui proposait ce service (signature d'un document avec horodatage). Est-ce que ça existe ?
      • [^] # Re: OpenSSL

        Posté par . Évalué à 5.

        Ben il y a verisign : le notaire du net...

        "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

    • [^] # Re: OpenSSL

      Posté par . Évalué à 1.

      Si ma mémoire ne me trahit pas, le seul rapport entre OpenSSH et OpenSSL ce sont les routines cryptographiques fournies par le second au premier via la libcrypto.
  • # Faites gaffe quand même...

    Posté par . Évalué à 10.

    ...y'a peut-être une backdoor des Chinois du FBI dans OpenSSH!

    Signé: Association des lecteurs en diagonale bourrés de DLFP

    -----------------> [ ]
    • [^] # Re: Faites gaffe quand même...

      Posté par . Évalué à 10.

      "lecteurs en diagonale bourrés de DLFP" dont la concentration croit entre le 24/12 et le 2/01 et à la sortie de chaque nouvelle ubuntu. Et je ne crois pas au coïncidence.

      Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

  • # Question

    Posté par . Évalué à 4.

    Si je comprends bien, le système de ControlPersist permettra donc de ne pas interrompre un terminal en cas de déconnexion ? Et permettra donc de le reprendre à la volé sans avoir besoin de se loguer à nouveau ?
    • [^] # Re: Question

      Posté par (page perso) . Évalué à 3.

      Ah, c'est pas du tout comme ça que je l'ai compris:
      Pour moi ça veut juste dire qu'il multiplexe toutes les connections ssh sur une seule connection TCP (mais j'ai l'impression que cette fonctionnalité existait déjà avant )
      • [^] # Re: Question

        Posté par . Évalué à 3.

        Pareil c'est aussi ce que je comprends et je ne vois pas la différence avec le Control Master (de mémoire).
        • [^] # Re: Question

          Posté par . Évalué à 6.

          Ok je viens d'essayer : en fait avant il fallait laisser la première connexion ouvert, dorénavant avant controlpersist cela est fait automatiquement en background.
      • [^] # Re: Question

        Posté par . Évalué à 3.

        Pour moi ça veut juste dire qu'il multiplexe toutes les connections ssh sur une seule connection TCP (mais j'ai l'impression que cette fonctionnalité existait déjà avant )
        Oui, ça existe déjà, étant donné qu'on peut même rajouter des redirections de port à la volée sans interrompre la connexion. Et ça passe forcément par la connection TCP existante.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Question

        Posté par (page perso) . Évalué à 4.

        De ce que j'avais compris, c'est que ça évitait de renégocier une session SSH à chaque fois qu'on voulait se connecter, ce qui était bien pratique pour certaines utilisation de tunnel où la renégociation est faite à chaque fois qu'il faut faire transiter des données.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Question

      Posté par (page perso) . Évalué à 2.

      C'est effectivement parfaitement incompréhensible en lisant la documentation officielle.

      C'est une option pour le côté client (même ça, ce n'est pas expliqué dans la doc, il faut deviner). Ca permet à plusieurs sessions de partager un même socket.
      Je ne sais pas à quoi ça sert (aucun exemple non plus dans la doc), mais il semble que ce soit bien pratique pour déporter X11.


      C'est une option qui existe depuis pas mal de temps (au moins 4 ou 5 ans), je ne sais pas pourquoi on en parle maintenant. Peut-être qu'avant c'était compilé optionnellement.
      • [^] # Re: Question

        Posté par (page perso) . Évalué à 8.

        Pourquoi on en parle que maintenant, parce qu'elle a un peu changé, cf plus haut.
        L'utilisation ?
        Par chez moi, les connexions TCP sont dropées si elles sont inactives plus de 5 minutes, si j'ouvre plusieurs ssh en même temps vers la même destination, il m'arrive que "j'oublie" certaines connexions, alors que d'autres restent actives.
        En passant par une socket, tout le monde resterait en vie :)
        • [^] # Re: Question

          Posté par (page perso) . Évalué à 5.

          Par chez moi, les connexions TCP sont dropées si elles sont inactives plus de 5 minutes
          Ouvrir plein de connexions n'empêche pas d'aller aux toilettes plus de 5 minutes, ni de répondre au téléphone :-)
          L'option "ClientAliveInterval 60" sur le serveur résout totalement ce problème. Avec en plus l'avantage de fermer les connexions qui ont été coupées par un routeur (sinon on a un joli processus ssh qui traîne sur le serveur). C'est totalement indépendant du client donc ça fonctionne avec Putty par exemple, ou un ssh quelconque sans avoir besoin de modifier sa configuration.
        • [^] # Re: Question

          Posté par (page perso) . Évalué à 2.

          Pourquoi on en parle que maintenant, parce qu'elle a un peu changé, cf plus haut.
          Je pige, la grosse différence est : qui reste actif aussi longtemps que désiré y compris après déconnexion de tous les clients locaux.
          Mais je ne sais toujours pas à quoi ça sert :-)
          • [^] # Re: Question

            Posté par (page perso) . Évalué à 4.

            Mais je ne sais toujours pas à quoi ça sert :-)

            De ce que j'ai compris, ça évite la renégociation liée à l'ouverture d'une session SSH. Ce qui est pratique dans certaines utilisation de tunnels SSH qui utilise une nouvelle session à chaque connexion.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # ControlPersist…

    Posté par (page perso) . Évalué à 10.

    La nouvelle option ControlPersist s'applique aux connexions utilisant l'option ControlMaster qui permettait déjà de multiplexer plusieurs connexions dans une seule session ssh.

    Les avantages du multiplexage sont entre autre un accès instantané aux connexions esclaves (c'est vraiment agréable pour l'autocompletion scp ou rsync) une seule session tcp (c'est le conntrack du firewall qui va être content…). Tout ceci est aussi très pratique sur les connexions utilisée comme proxy SSH – avec l'option -W évidemment…
    Les inconvénients sont : la connexion maître doit rester ouverte tant qu'il y a des esclaves sur la socket (un simple ^D ne ferme que le shell mais laisse la connexion ouverte en général sans retour ou prompt local par contre, il ne faut pas fermer le terminal…), les commandes « escape » sont renvoyées sur la connexion maître (gênant quand il y a un vi ouvert, un tail qui défile ou autre sur ce terminal)

    L'option ControlPersist permet de s'affranchir du premier inconvénient en créant la connexion maître en arrière plan sans terminal associé ni processus père (peut-être déjà possible avec quelque chose du genre « ssh -fT » mais je n'ai pas essayé). Le second peut-être compensé par l'option « -O forward », les redirections créées sont affectées à la connexion maître et survivent à la fermeture de toutes les sessions. Attention si on met cette option est à yes, la connexion restera ouverte indéfiniment jusqu'à ce quelle soit tuée ou qu'on lui envoie la commande d'arrêt « ssh -O exit », il vaut certainement mieux lui affecter un délai (1d chez moi) au bout duquel elle se ferme si aucun terminal n'est utilisé…
    Côté serveur, il n'y a pas vraiment de différence avec cette option, je m'attendais à un fork supplémentaire, mais ce n'est pas le cas, donc pas vraiment d'impact négatif (à part des connexions qui peuvent rester ouvertes sans qu'on s'en aperçoive).

Suivre le flux des commentaires

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