67 chaussettes pour OpenSSH

Posté par Sytoka Modon (site web personnel) le 16 octobre 2014 à 02:39. Édité par Davy Defaud, Benoît Sibaud et patrick_g. Modéré par Xavier Teyssier. Licence CC By‑SA.

Étiquettes :

oct.

2014

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.

Aller plus loin

Notes de version (44 clics)
Annonce sur LWN (26 clics)
Site web d’OpenSSH (49 clics)
OpenSSH sur Wikipedia (36 clics)

# Chaussette ! (coucou le nain)

Posté par 🚲 Tanguy Ortolo (site web personnel) le 16 octobre 2014 à 09:33. É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.
- [^] # Re: Chaussette ! (coucou le nain)
  
  Posté par xcomcmdr le 16 octobre 2014 à 10:35. Évalué à 7.
  
  SSH est enfin niveau 2 ?
  
  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
  - [^] # Re: Chaussette ! (coucou le nain)
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 16 octobre 2014 à 17:50. Évalué à 4.
    
    Ah, je vois qu'on suit !
    - [^] # Re: Chaussette ! (coucou le nain)
      
      Posté par freem le 17 octobre 2014 à 12:02. Évalué à 2.
      
      Bon ça, ça veut dire qu'on pourra faire encore chier le groupe!
# TCPWrapper

Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 16 octobre 2014 à 11:14. É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 ?

« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
- [^] # Re: TCPWrapper
  
  Posté par octane le 16 octobre 2014 à 11:21. É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 Sytoka Modon (site web personnel) le 16 octobre 2014 à 11:25. É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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 16 octobre 2014 à 12:04. É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 ?
    
    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
  - [^] # Re: TCPWrapper
    
    Posté par neologix le 16 octobre 2014 à 20:55. É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… :)
    - [^] # Re: TCPWrapper
      
      Posté par Sytoka Modon (site web personnel) le 16 octobre 2014 à 21:23. Évalué à 4.
      
      Enfin un qui a mordu ;-)
# Forward/tunnel

Posté par jean_clume le 16 octobre 2014 à 17:08. É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 🚲 Tanguy Ortolo (site web personnel) le 16 octobre 2014 à 17:54. É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 Kioob (site web personnel) le 16 octobre 2014 à 19:16. É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 Sytoka Modon (site web personnel) le 16 octobre 2014 à 20:07. Évalué à 4.
      
      Ceci dis, ce n'est pas une mauvaise idée de désactivé pour MySQL ;-)
      - [^] # Re: Forward/tunnel
        
        Posté par Kioob (site web personnel) le 16 octobre 2014 à 20:21. É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 jean_clume le 16 octobre 2014 à 22:02. É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 Cyril Brulebois (site web personnel) le 17 octobre 2014 à 06:14. É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 benoar le 17 octobre 2014 à 11:52. É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 Kioob (site web personnel) le 17 octobre 2014 à 13:55. É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 🚲 Tanguy Ortolo (site web personnel) le 17 octobre 2014 à 15:20. É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 Dabowl_75 le 17 octobre 2014 à 14:47. É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 ?
- [^] # Re: CBC & arcfour
  
  Posté par zul (site web personnel) le 17 octobre 2014 à 15:54. Évalué à 1.
  
  C'est peu fiable cryptographiquement parlant (cf http://www.wisdom.weizmann.ac.il/~itsik/RC4/rc4.html). Même Microsoft recommande de le désactiver, comme quoi je ne lui ferai vraiment pas confiance (voir la page wikipedia anglaise quoi …)