OpenSSH 5.6 est disponible

Posté par claudex le 26 décembre 2010 à 22:42. Modéré par Xavier Teyssier.

Étiquettes :

déc.

2010

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.

Aller plus loin

OpenSSH (18 clics)
OpenBSD (7 clics)
Notes de sortie (4 clics)

# Nouveau format de certificat de clef

Posté par barmic le 26 décembre 2010 à 23:15. É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 ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Nouveau format de certificat de clef
  
  Posté par Krunch (site web personnel) le 27 décembre 2010 à 03:59. É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 Earered le 27 décembre 2010 à 01:24. É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 KiKouN le 27 décembre 2010 à 08:01. É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 J Avd le 27 décembre 2010 à 11:41. É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 natsirt le 29 décembre 2010 à 18:25. É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 Maclag le 27 décembre 2010 à 04:10. É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 Julien Gilbert le 27 décembre 2010 à 09:35. É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 Anonyme le 27 décembre 2010 à 16:07. É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 Ph Husson (site web personnel) le 27 décembre 2010 à 17:09. É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 Romeo le 27 décembre 2010 à 17:18. É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 Romeo le 27 décembre 2010 à 17:23. É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 Grunt le 27 décembre 2010 à 17:29. É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 claudex le 27 décembre 2010 à 18:13. É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 Kerro le 27 décembre 2010 à 17:34. É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 Ph Husson (site web personnel) le 27 décembre 2010 à 17:51. É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 Kerro le 27 décembre 2010 à 20:29. É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 Kerro le 27 décembre 2010 à 20:34. É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 claudex le 27 décembre 2010 à 23:51. É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 Hobgoblins Master (Mastodon) le 28 décembre 2010 à 12:51. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.