67 chaussettes pour OpenSSH

Posté par (page perso) . Édité par Davy Defaud, Benoît Sibaud et patrick_g. Modéré par Xavier Teyssier. Licence CC by-sa
Tags :
57
16
oct.
2014
Sécurité

Le 6/10, OpenSSH est sortie en version 6.7. Faut‐il vraiment dire ici ce que fait OpenSSH ou est‐ce dans l’inconscient collectif des libristes ? En très bref, c’est un serveur et un client du protocole SSH, digne descendant de telnet, qui ajoute pas mal de truc comme la redirection de ports…

Quoi de neuf en octobre ?

  • Les algorithmes de chiffrement par défaut ont été changés et notamment CBC et Arcfour ont été désactivés (pas supprimés, il est toujours possible de les activer).

  • La prise en charge de la bibliothèque tcpwrapper a été supprimé. Cela pose, par exemple, des problèmes pour la future Debian Jessie car c’était une fonctionnalité encore souvent utilisée par de nombreux utilisateurs. Debian a décidé de maintenir via un correctif la fonctionnalité pour le moment (voir les commentaires sur LWN).

  • La factorisation du code source continue afin d’améliorer le cœur en vue de fournir une bibliothèque utilisable de manière indépendante. Cependant, le travail n’est pas encore parfait du coté de l’interface de programmation (API), donc la bibliothèque n’est pas encore mise en avant.

  • ssh et sshd intègrent la prise en charge de la transmission (forward) des sockets UNIX. Un port TCP distant peut être connecté à un socket UNIX local et réciproquement. De même, on peut connecter deux sockets UNIX ! Cette fonctionnalité n’était possible jusqu’à présent que pour X-Window via l’option -X, elle ouvre de grands horizons dans l’usage distant d’un poste de travail.

  • Ajout de la séquence d’échappement %C dans le client ssh pour les commandes LocalCommand et ControlPath. %C représente un condensat (hash) du tuple (hôte local, utilisateur distant, hôte distant, port). L’objectif est de pouvoir avoir un nom de fichier court et unique, car sur certains UNIX, on pouvait dépasser la limite du système pour les noms de fichiers correspondant aux sockets UNIX !

Il y a encore pas mal de petites choses concernant le chiffrement, les procédures de test et de robustesse… Le mieux pour les passionnés est de lire la note de version pour avoir une vision détaillée et complète.

  • # Chaussette ! (coucou le nain)

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

    ssh et sshd intègrent le support pour transmettre (forward) les sockets UNIX. Un port TCP distant peut être connecté à une socket Unix local et réciproquement. De même, on peut connecter deux sockets Unix ! Cette fonctionnalité n'était possible jusqu'à présent que pour X-Window via l'option -X, elle ouvre de grand horizon dans l'usage distant d'un poste de travail.

    Et pour les agents SSH via l'option -A.

  • # TCPWrapper

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

    Pourquoi abandonner le support de TCPWrapper ?
    Pour les gens peu versés dans les réseaux, c'est tout de même un outil très pratique pour gérer les autorisations de connexion sur les serveurs d'une machine. Quelqu'un sait-il pourquoi openSSH décide d'abandonner le support de cette fonctionnalité clef ?

    • [^] # Re: TCPWrapper

      Posté par . Évalué à 6.

      L'auteur du nourjal donne un lien : http://lwn.net/Articles/615173/ qui dit en parler, et cette page dirige vers http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html

      En gros:

      • La cible Match du fichier de conf fait les choses mieux que TCPWrapper
      • Cela enlève du vieux code qui tourne en mode préauthentification (le code le plus risqué)
    • [^] # Re: TCPWrapper

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

      J'ai cru comprendre que les développeurs considèrent que la commande Match introduite il y a maintenant pas mal d'année permettait de faire la même chose, ils veulent donc supprimer une dépendance. Ceci dis, je n'ai pas été voir de plus près, il y a peut être des raisons plus technique. Colin Watson, le mainteneur Debian, semble dire que la dépendance est très faible dans le code puisqu'il ne s'agit que de quelques lignes. Affaire à suivre…

      • [^] # Re: TCPWrapper

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

        Bien entendu il est possible de faire « la même chose » autrement avec openSSH. Heureusement. Mais, sauf erreur de ma part, cela n'a pas la même portée que TCPWrapper. Qui tant qu'il était utilisé dans toute la distribution permettait d'appliquer des règles très simplement pour toutes les connexions TCP. Ce qui évite d'avoir à se préoccuper de fichiers de configuration par serveur d'un côté, ou de se farcir des règles iptables (sensiblement plus complexes) de l'autre.

        Si je comprends bien les discussions dans les liens données, l'abandon de TCPWrapper serait liée à l'obsolescence de cette librairie plus ou moins abandonnée par ses développeurs depuis 1997 ?

      • [^] # Re: TCPWrapper

        Posté par . Évalué à 10.

        Colin Watson, le mainteneur Debian, semble dire que la dépendance est très faible dans le code puisqu'il ne s'agit que de quelques lignes. Affaire à suivre…

        Ca me rappelle quelque chose, un patch de quelques lignes maintenu par Debian dans un projet commençant par OpenSS… :)

  • # Forward/tunnel

    Posté par . Évalué à 1.

    ssh et sshd intègrent le support pour transmettre (forward) les sockets UNIX. Un port TCP distant peut être connecté à une socket Unix local et réciproquement. De même, on peut connecter deux sockets Unix ! Cette fonctionnalité n'était possible jusqu'à présent que pour X-Window via l'option -X, elle ouvre de grand horizon dans l'usage distant d'un poste de travail.

    Si je vois bien ce qu'est le X11 forwarding, je ne comprend pas quelles sont les usages du forward par rapport aux tunnels locaux ou distants? Un exemple d'utilisation?

    • [^] # Re: Forward/tunnel

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

      Jusqu'à présent, on pouvait définir des tunnels de connexions TCP. Maintenant, on peut faire pareil avec des sockets Unix. Un socket Unix, c'est comme un socket réseau avec une adresse IP et un port, sauf que ça ne se passe pas sur le réseau mais en local, et qu'au lieu d'avoir une adresse et un port, c'est identifié par un fichier d'un type spécial (de type socket, pour être précis, évidemment). Ainsi, un logiciel peut se connecter sur, par exemple sur quelque chose comme /tmp/pulse/socket, où écoute un autre logiciel, pour y envoyer du son, que cet autre logiciel jouera sur la carte son, dans cet exemple.

      • [^] # Re: Forward/tunnel

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

        D'ailleurs, un cas concret rencontré ce soir : intervention sur un serveur MySQL d'un nouveau client. Je n'ai qu'un simple accès SSH sans privilège particulier, il n'y a aucun outil de diagnostique sur le serveur.

        Habituellement, dans ces conditions je crée un tunnel SSH entre une machine ayant les outils en questions et le serveur en question. Manque de bol, le client a complètement désactivé le réseau dans son MySQL (--skip-networking), et il est uniquement en écoute sur un socket local.

        Cette nouvelle fonctionnalité me permettra donc de continuer à utiliser un tunnel SSH, et ainsi utiliser mes outils, de manière transparente.

        alf.life

        • [^] # Re: Forward/tunnel

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

          Ceci dis, ce n'est pas une mauvaise idée de désactivé pour MySQL ;-)

          • [^] # Re: Forward/tunnel

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

            Yep, mais pour ma part je préfère un "listen ::1", qui reste compatible avec les tunnels SSH ;)

            C'est d'ailleurs le choix par défaut sous Debian je crois, depuis quelques années.

            alf.life

        • [^] # Re: Forward/tunnel

          Posté par . Évalué à 2.

          Wow!
          Je me sers des tunnels pour laisser mes services écouter sur l'interface local uniquement là un pas supplémentaire est franchi.
          Dans le cas de Mysql c'est effectivement super pratique.

        • [^] # Re: Forward/tunnel

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

          Cette nouvelle fonctionnalité me permettra donc de continuer à utiliser un tunnel SSH, et ainsi utiliser mes outils, de manière transparente.

          On peut effectivement gagner en transparence mais on peut noter qu'il est déjà possible d'utiliser socat pour transformer une socket UNIX en une socket TCP, qu'on peut ensuite trimballer avec les redirections de port (locales ou distantes), et au besoin retransformer de socket TCP en socket UNIX de l'autre côté.

          (Contexte typique : /var/run/pcscd/pcscd.comm, PKCS#11, etc.)

          Debian Consultant @ DEBAMAX

          • [^] # Re: Forward/tunnel

            Posté par . Évalué à 2.

            Exactement, un socat au bout d'un ssh ça peut être très pratique. Après, avoir d'office cette fonctionnalité dans OpenSSH est pratique quand socat n'est pas disponible sur la machine.

            Perso, avec socat j'ai pu bidouiller des montages sftp root en se loggant en simple utilisateur mais en utilisant sudo.

          • [^] # Re: Forward/tunnel

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

            Roh je t'aime :) Je ne connaissais absolument pas, bricolant des solutions plus ou moins moches à chaque fois.

            alf.life

          • [^] # Re: Forward/tunnel

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

            On peut effectivement gagner en transparence mais on peut noter qu'il est déjà possible d'utiliser so>cat pour transformer une socket UNIX en une socket TCP,

            Si tu es le seul à avoir accès à ces machines, pourquoi pas, mais sinon, mauvaise idée, parce qu'un socket TCP, tous les utilisateurs du système peuvent s'y connecter. Il serait sans doute plus judicieux d'utiliser socat, mais pour faire passer ça sur un descripteur de fichiers supplémentaire, si c'est possible.

  • # CBC & arcfour

    Posté par . Évalué à 2.

    C'est quoi le problème avec arcfour ?

    Car je m'en sert assez régulièrement pour accélerer les gros transferts de fichier avec scp.

    Quel cipher peut offrir les mêmes performances ?

Suivre le flux des commentaires

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