OpenSSH v5.4 : Certificat et Révocation

Posté par  (site web personnel) . Modéré par baud123.
Étiquettes :
58
15
mar.
2010
Sécurité
Si je ne me trompe, la dernière annonce sur LinuxFr concernant OpenSSH date d'octobre 2006, c'était la version 4.4. Depuis, du boulot, des améliorations mais dans la continuité. Cependant, le 8 mars 2010 tombe dans les bacs la version 5.4 qui apporte des changements de grandes ampleurs qui sont passés en revue dans la seconde partie de la dépêche.

Petite présentation pour commencer: OpenSSH implémente un client et un serveur pour les différentes versions du protocole SSH ainsi que le support pour le SFTP (à ne pas confondre avec le FTPS qui est du FTP dans un tunnel SSL). OpenSSH est distribué sous licence libre BSD et c'est un peu le fer de lance des développeurs d'OpenBSD. Il permet de se connecter à distance sur une machine et intègre un nombre impressionnant d'opérations utiles : shell distant, transfert de fichier, redirection de ports, tunnel... Les changements importants dans la version 5.4 sont listés ci-dessous :

- La version 1 du protocol SSH est maintenant désactivée par défaut. Cela fait 10 ans que ce protocole est obsolète et il faudra désormais explicitement l'activer si l'on souhaite l'utiliser vers les rares machines qui ne peuvent migrer vers une version supérieure.

- Ajout du support pour les tokens PKCS#11 en lieu et place de l'ancien code concernant OpenSC. PKCS#11 a été développé par les laboratoires RSA et définit une interface (API) pour gérer les périphériques cryptographiques.

- Ajout d'un nouveau système d'authentification par certificat en plus du système par clefs. Le format choisi est propre à OpenSSH et n'est pas le X.509 (cela semble au premier abord un peu dommage). Les certificats des machines ou des personnes contiennent un clef publique, l'identité de la personne ou de la machine, une plage de validité temporelle (début et/ou fin) et sont signés par une clef publique SSH standard. Toutes ces opérations se réalisent avec le même programme que pour générer des clef : ssh-keygen.

Les clefs maîtresses (CA keys) faisant autorité doivent être déclarées comme telles, soit dans le fichier authorized_keys ou sshd_config (via la nouvelle directive TrustedUserCAKeys) pour les certificats utilisateurs, soit dans le fichier known_hosts pour l'authentification de machine.

- Complémentaire du point précédent, il est maintenant possible de révoquer des clefs. Le bogue introduit dans OpenSSL par Debian avait montré les limites d'un système sans révocation et sans date limite... À l'époque, les développeurs Debian avaient mis en urgence un système de révocation.

Le système mis en place dans OpenSSH est assez simple, le paramètre de configuration du serveur "RevokedKeys" indique un fichier donnant la liste des clefs interdites : cela peut être indifféremment des clefs serveurs ou utilisateurs.

- Ajout d'un mode "netcat" avec l'option -W (l'option -w est pour les tunnels). La commande ssh -W host:port connecte donc les entrées sorties (stdio) du client vers un unique port sur le serveur.

Il y a aussi quelques améliorations que l'utilisateur verra certainement moins facilement :

- Le multiplexage permettant de mélanger plusieurs sessions ssh dans le même tuyau supporte maintenant les opérations non bloquantes améliorant ainsi la latence. De plus, il est maintenant possible de rajouter des transferts de port (port forwarding) ainsi des transfert d'entrée/sortie (stdio -> netcat) dans le canal multiplexé.

- Amélioration dans le sous-système SFTP du serveur. Il est désormais possible d'avoir un mode en lecture seule. Dans le même esprit, la valeur du masque umask peut être explicitement définie et ne peut alors être surchargée par l'utilisateur (Voir sftp-server). D'un point de vue interface homme-machine, la commande "ls" supporte maintenant l'option "-h" qui affiche les unités sous un format plus facile pour un utilisateur. La ligne de commande supporte maintenant la complétion pour les commandes, les noms des fichiers sur le système local ou sur le système distant. Les commandes "get" et "put" supportent maintenant les transferts récursifs via une option.

- La plupart des options de la ligne de commande de "scp" sont maintenant supportées par "sftp". L'objectif à terme est tout simplement de remplacer "scp" par "sftp". Pour ce faire, et pour homogénéiser les options de ces deux commandes, l'ancienne option peu usitée -P de sftp qui donnait le chemin du serveur sftp devient l'option -D. En effet, cette option -P sert maintenant comme dans scp à fixer le port du serveur.

- Les nouvelles clefs RSA seront maintenant générées avec un exposant fixé à 65537 (RSA_F4 = 2^16+1) en lieu et place de l'ancienne valeur 35.

- Les clefs privées protégées par passphrase sont maintenant chiffrées avec l'algorithme AES-128 à la place du 3DES utilisé jusqu'à présent. En cas de modification de leur passphrase, les anciennes clefs bénéficieront de ce nouveau chiffrement.

Au final, un grand cru on l'espère. Vivement la version 6.4 !

Aller plus loin

  • # Excellent.

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

    Excellent.

    ssh est l'un des plus formidables et utiles outils réseau jamais créés.
    Console distante, transfer de fichiers, tunnelling... tout ça sécurisé, ça rend beaucoup de services.

    Et je ne parle pas des applications greffées là dessus, comme NX (magnifique).

    Il ne manque plus qu'une encapsulation HTTP... je rêve ?
    (oui je sais il y a GnuHttpTunnel, OpenVPN...)

    • [^] # Re: Excellent.

      Posté par  . Évalué à 5.

      Y'a pas déjà une encapsulation HTTP?

      Je crois me souvenir être passé par un proxy HTTP dans Putty, en faisant du SSH, sans configuration particulière du serveur.

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

      • [^] # Re: Excellent.

        Posté par  (Mastodon) . Évalué à 6.

        Transfert de port, tu rediriges le port 80 de la source de la connexion (ta machine) vers un proxy du côté de la destination et hop, gagné.
        Par contre il faut un proxy, et utiliser en configuration locale ta propre machine en tant que proxy.
        Les requêtes passent donc en local, hop dans le tunnel et ressortent pour se jeter dans le proxy distant, voyagent sur le grand Nain Ternète, et reviennent en se faufilant dans le tunnel, nahaha !

        Voilà...

        Yth.

        • [^] # Re: Excellent.

          Posté par  . Évalué à 6.

          Proxy SOCKS : ssh -D 8080 root@machinedistante

          Et tu configure ton navigateur pour utiliser localhost:8080 en proxy

          • [^] # Re: Excellent.

            Posté par  . Évalué à 2.

            J'utilise ce système sur mon laptop pour les cas où celui-ci serait connecté à un wifi pas secure. Thunderbird est configuré avec ce proxy par défaut, ainsi je suis tranquille quand je récupère mes mails à la bibliothèque.

            Sinon, j'espère que cette nouvelle version facilite l'utilisation de clé et de certificat, j'ai toujours eu un mal fou à faire fonctionner un accès ssh en utilisant un clé à place du mdp utilisateur.

        • [^] # Re: Excellent.

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

          Je peux me tromper, mais il me semble que c'est le contraire qui est recherché: encapsuler une connexion SSH dans un flux HTTP(S), parce que certains proxies paranoïaques n'autorisent pas la méthode CONNECT (d'où des softs comme HttpTunnel).

          C'est vrai que c'est sans doute une fonctionnalité qui aurait sa place dans le cœur d'OpenSSH. Ce qui serait pas mal, ce serait un module Apache HTTPD qui intercepterait les requêtes sur le port 443 et qui saurait "router" vers un OpenSSH (histoire de passer à travers les gentils proxies qui non seulement n'autorisent pas CONNECT, mais en plus n'autorisent SSL que sur le 443).

          • [^] # Re: Excellent.

            Posté par  . Évalué à 2.

            Ce qui serait pas mal, ce serait un module Apache HTTPD qui intercepterait les requêtes sur le port 443 et qui saurait "router" vers un OpenSSH

            Ce n'est pas un module Apache, mais ça ressemble à ce que tu cherches, non?

            http://search.cpan.org/~book/Net-Proxy-0.08/script/sslh

          • [^] # Re: Excellent.

            Posté par  . Évalué à 2.

            Pour cela, il y a corkscrew qui permet de passer par un proxy. Et en plus, il fait partie de la distribution cygwin. Un ajout dans la config du sshd chez soi pour qu'il écoute sur le 443 (ou bien une redirection sur le routeur) et hop, on est connecté à la maison :-D

            • [^] # Re: Excellent.

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

              Extrait du man corkscrew :

              corkscrew is a simple tool to tunnel TCP connections through an HTTP proxy supporting the CONNECT method

              Comme dit plus haut, l'utilisation de corkscrew suppose que le proxy accepte un CONNECT. Même si c'est seulement sur le port 443, les proxy qui acceptent celà restent assez friendly. Ce n'est pas le cas de tous les proxies, comme évoqué plus haut. Dans ce cas, corkscrew n'est d'aucune utilité et il faut encapsuler sa connexion dans des requêtes HTTP...

              • [^] # Re: Excellent.

                Posté par  . Évalué à 1.

                Moi qui croyait que notre proxy était une *beeeeeep*, je suis corrigé, il y a encore pire... Désolé pour cette fausse piste /o\

                • [^] # Re: Excellent.

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

                  oui tout ça ne marche pas.

                  Je suis dans le cas d'un proxy qui n'accepte pas CONNECT, du coup la quasi-totalité des outils ne fonctionnent pas (corkscrew et autres).

                  Quelques pistes que je n'ai pas encore eu le temps d'explorer:
                  http://www.sensepost.com/research/reDuh/
                  http://en.wikipedia.org/wiki/BOSH
                  http://sebastien.lebreton.free.fr/bdtunnel/
                  http://sourceforge.net/projects/webtunnel/

                  • [^] # Re: Excellent.

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

                    > Je suis dans le cas d'un proxy qui n'accepte pas CONNECT

                    Comment tu fais pour aller sur des sites en HTTPS (au hasard, moulefr) ?

                    • [^] # Re: Excellent.

                      Posté par  . Évalué à 3.

                      Squid (il me semble) peut très bien faire l'intermédiaire https sans CONNECT, mais bien sûr, en substituant son propre certificat à celui du site, ce qui casse complètement le principe de sécurité de https.

                      • [^] # Re: Excellent.

                        Posté par  . Évalué à 1.

                        Squid (il me semble) peut très bien faire l'intermédiaire https sans CONNECT, mais bien sûr, en substituant son propre certificat à celui du site, ce qui casse complètement le principe de sécurité de https.
                        Pour arriver à faire ça sans avoir une avalanche d'avertissements (mais quand même au moins un) sur le navigateur il faut utiliser un certificat autosigné et du DNS spoofing pour chaque serveur HTTPS qui doit être visité. À ce prix là autant autoriser le CONNECT à une whitelist contenant ces mêmes sites. Ce sera moins sale et plus simple à mettre en oeuvre.

                      • [^] # Re: Excellent.

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

                        À peine plus que les certificats auto-signés ;-)

      • [^] # Re: Excellent.

        Posté par  . Évalué à 7.

        Il y a un proxy SOCKS dans OpenSSH.
        Qui permet de naviguer, télécharger, ... à travers un serveur SSH.

        Sur la machine cliente (qui possède le navigateur internet)

        ssh user@remotehost -D8080

        8080 = port a configurer dans le navigateur pour la connexion SOCKS. (localhost:8080)
        Et voilà, tant que le tunnel SSH reste ouvert vous surfez via la machine distante.

        Dans Firefox (linux),
        Edition - Préférences - Avancés - Réseau - Connexion - Paramètres - Configuration manuelle du proxy:
        Hote SOCKS: localhost
        port: 8080

        • [^] # Re: Excellent.

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

          Et ne pas oublier de faire un tour dans about:config pour remettre "network.proxy.socks_remote_dns" à true, pour éviter que les requêtes DNS ne soient interceptées par n'importe qui sur le réseau local que tu peux avoir le malheur d'utiliser...

          • [^] # Re: Excellent.

            Posté par  . Évalué à 4.

            Ou bien utiliser un navigateur Webkit où ce comportement est configuré d'emblée.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Excellent.

          Posté par  . Évalué à 3.

          On en apprend tout les jours.

          Et moi qui me faisait chier a installer srelay sur mon serveur et a forwarder les ports par ssh...

          Je ne parle pas en école d'inge ou l'on utilisait slirp sur le shell distant ouvert par ssh, pour recupurer en local un lien ppp...

        • [^] # Re: Excellent.

          Posté par  . Évalué à 2.

          je viens d'essayer, je precise comme ce n'est pas trés clair, que la partie serveur openssh, ordinateur distant, se demmerde tout seul, il n'y a rien a configurer de ce coté

          c'est vraiment etonnant, et trés pratique :)

  • # Incontournable

    Posté par  . Évalué à 10.

    Vraiment incontournable dans des situations désespérées. Exemple :

    Pas plus tard que samedi matin, je reçois un appel d'un ami qui n'arrivait pas à faire fonctionner une appli sur son portable.

    Il avait une machine virtuel sous Virtual Box OSE qui faisait tourner un serveur de client léger sur le réseau filaire. Le tout fonctionnait (ou plutôt ne fonctionnait pas) sur un portable ayant un accès Internet par le WiFi via un portail captif universitaire.

    Voici les étapes du dépannage :
    * il a installé OpenSSH server sur son portable
    * il s'est connecté sur un serveur publique sur Internet avec tunnel rentrant ;
    * je me suis connecté sur le même serveur publique sur Internet avec tunnel sortant ;
    * j'ai relié les 2 bouts des tunnels ;
    * j'ai pu alors ouvrir de chez moi une connexion SSH directement sur son portable ;
    * on a reconfiguré la VM pour disposer d'un connexion réseau privée avec le portable ;
    * j'ai alors ouvert une connexion SSH sur la VM ;
    * j'ai enfin ouvert une dernière connexion SSH vers le client léger pour diagnostiquer le problème ;

    Il faut parfois un peu d'aspirine pour enchainer les tunnels SSH mais c'est vraiment incontournable et terriblement efficace !

    • [^] # Re: Incontournable

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

      C'était assez épic d'ailleurs, sacré performance le PhE \o/
      Merci encore ;-)

    • [^] # Re: Incontournable

      Posté par  . Évalué à 3.

      * il s'est connecté sur un serveur publique sur Internet avec tunnel rentrant ;
      * je me suis connecté sur le même serveur publique sur Internet avec tunnel sortant ;
      * j'ai relié les 2 bouts des tunnels ;

      Je suppose que c'est à cause du NAT ; moi je dis vivement que l'IPv6 se généralise pour qu'on arrête ce genre de bidouille.
      D'ailleurs, s'il avait en plus configuré sa VM dans un subnet sur sa machine, tu aurais juste pu faire un simple ssh directement sur l'adresse de la VM ... !
      Les bidouilles c'est bien, mais quand on peut les éviter, c'est mieux...

      • [^] # Re: Incontournable

        Posté par  . Évalué à 3.

        Je suppose que c'est à cause du NAT ; moi je dis vivement que l'IPv6 se généralise pour qu'on arrête ce genre de bidouille.

        Pas vraiment à cause du NAT mais plutôt des parre-feu.
        Je suppose que même en IPv6 la majorité des "box" et autres passerelles seront configurées pour autoriser les connexions sortantes et bloquer les entrantes.

        D'ailleurs, s'il avait en plus configuré sa VM dans un subnet sur sa machine, tu aurais juste pu faire un simple ssh directement sur l'adresse de la VM ... !

        Un subnet de quel réseau ?
        Si c'est un nouveau réseau, le routage local sur sa machine n'aurait pas suffit. Les passerelles intermédiaires n'auraient pas connaissance de ce subnet. Et la conf d'un subnet et de règles de routage est autrement plus délicate à faire faire à distance à un utilisateur qu'un :
        ssh -R1234:localhost:22 toto@monrelais.com
        Les bidouilles c'est bien, mais quand on peut les éviter, c'est mieux...

        En dépannage, la bidouille c'est souvent ce qui te sauve la vie !
        Dans le cas présent, on a pu reconstruire une image de 10 Go à distance et malgré plusieurs coupures WiFi (merci SSH+screen).

        • [^] # Re: Incontournable

          Posté par  . Évalué à 3.

          Je suppose que même en IPv6 la majorité des "box" et autres passerelles seront configurées pour autoriser les connexions sortantes et bloquer les entrantes.

          Là j'avoue que je ne sais pas trop ce qu'il en sera ... Effectivement, vu la fiabilité des machines sous l'OS de MS quand elles sont directement exposées au net, il est probable que le firewall soit configuré pour tout bloquer par défaut. Mais j'espère qu'on pourra au moins facilement désactiver ce truc (voire sélectivement).

          Un subnet de quel réseau ?

          Du préfixe qui t'est attribué par ton FAI. En général, tu as un minimum un /56, t'as donc de la place pour créer ce que tu veux ...

          Si c'est un nouveau réseau, le routage local sur sa machine n'aurait pas suffit. Les passerelles intermédiaires n'auraient pas connaissance de ce subnet.

          Les gens habitués à IPv4 pensent toujours à "sous-réseau privé" : non, là on fera un sous-réseau public, routable.

          Et la conf d'un subnet et de règles de routage est autrement plus délicate à faire faire à distance à un utilisateur qu'un :

          ssh -R1234:localhost:22 toto@monrelais.com

          La conf d'un masquerading est aussi "compliquée" que la conf d'un subnet. Sauf que c'est fait automatiquement par ta box ou le script de montage de ta VM. Et bah là ce sera pareil avec le subnet. C'est juste que maintenant il n'y aura plus de tunnel à faire. Moi, j'en conclue "plus simple".

          En dépannage, la bidouille c'est souvent ce qui te sauve la vie !

          Oui, effectivement, ce dont je parlais valais plutôt dans un cas "général". Quand tu dois rapidement dépanner quelqu'un, tu fais avec ce que tu as. Forcément, là, tu n'avais pas d'IPv6, mais si c'était plus répandu ...

          Dans le cas présent, on a pu reconstruire une image de 10 Go à distance et malgré plusieurs coupures WiFi (merci SSH+screen).

          Là je pense que tu peux surtout dire merci à TCP (et screen quand ça coupe vraiment). SSH n'a rien à faire là-dedans, et ça marcherait aussi bien sans tunnel avec IPv6.

          • [^] # Re: Incontournable

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

            >Du préfixe qui t'est attribué par ton FAI. En général, tu as un minimum un /56, t'as donc de la place pour créer ce que tu veux ...
            Réseaux de l'université, avec un proxy itou :S

            • [^] # Re: Incontournable

              Posté par  . Évalué à 2.

              Réseaux de l'université, avec un proxy itou :S

              Je parlais dans le cas d'IPv6. Je n'ai pas tout à fait compris ta réponse ...

          • [^] # Re: Incontournable

            Posté par  . Évalué à 1.

            >il est probable que le firewall soit configuré pour tout bloquer par défaut. Mais j'espère qu'on pourra au moins facilement désactiver ce truc (voire sélectivement).

            Bin, tu peux déjà le faire en IPv4, je ne vois pas pourquoi ils retireraient cette possibilité en IPv6..

            • [^] # Re: Incontournable

              Posté par  . Évalué à 4.

              Bin, tu peux déjà le faire en IPv4, je ne vois pas pourquoi ils retireraient cette possibilité en IPv6..

              Pas exactement. Les box faisant du NAT, forcément les machines qui sont derrière sont comme si elles étaient "firewallées" par défaut. Tu dois explicitement faire du port-forwarding (et savoir quel port sur quelle machine) pour "ouvrir" tes bécanes à l'extérieur. Avec IPv6, t'aurais juste à dire "ouvre moi tout", ou "ouvre moi tout pour cette machine". Ce n'est pas tout à fait pareil.

              • [^] # Re: Incontournable

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

                Du point de vue du routeur–pare-feu, NAT ou exposition directe des machines qui sont derrière, c'est kif-kif. Dans un cas, c'est NAT et PAT fixe à la demande. Dans l'autre cas, c'est blocage des connexion entrantes et déblocage à la demande.

                • [^] # Re: Incontournable

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

                  Enfin, kif-kif c'est gentil.

                  Le NAT est une vrai daube pour les protocole un peu complexe comme le H323 ou le SIP... Donc pour essayer de faire marcher les bousins, on passe par des serveurs en IP publique et on perds une partie de l'esprit d'internet de faire du point à point mais surtout de faire simple.

                  Donc, oui le NAT n'apporte aucune sécurité supplémentaire et oui le NAT rend les choses bien plus complexe.

                  En fait, le NAT est une mauvaise invention qui nous a fait perdre 10 ans et qui aura complexifié inutilement toutes les applications réseaux.

                  • [^] # Re: Incontournable

                    Posté par  . Évalué à 5.

                    En fait, le NAT est une mauvaise invention qui nous a fait perdre 10 ans et qui aura complexifié inutilement toutes les applications réseaux.

                    Je pense qu'aucune étude du coût du NAT par rapport à la migration à IPv6 ne sortira jamais, ça ferait trop peur. (mais oui, c'est clair qu'on n'aurait pas avancé "si vite" au début ; par contre, après ...)

                  • [^] # Re: Incontournable

                    Posté par  . Évalué à 1.

                    Le NAT est une vrai daube pour les protocole un peu complexe comme le H323 ou le SIP.

                    C'est clair, mais il faudrait peut-être aussi s'en prendre à ceux qui ont rédigés ces protocoles qui ne prennent pas en compte les connexions NATés, alors qu'elles sont nombreuses.
                    A moins qu'ils ne les ait fait ainsi pour permettre aux sociétés de sécurité de vendre de nouveaux produit qui savent remonter au niveau 7 ?

                    • [^] # Re: Incontournable

                      Posté par  . Évalué à 3.

                      Après une rapide vérification, le NAT et H323 sont arrivés à peu près en même temps (mi-90). Le NAT était censé être un hack qui ne durerait pas, et H323 devait devenir le protocole de VoIP. Bon, l'histoire fait que c'est l'"inverse" (si on peut dire) qui s'est passé, donc forcément, les concepteurs d'H323 n'avaient pas prévu ça.

                      • [^] # Re: Incontournable

                        Posté par  . Évalué à 2.

                        Bon ok pour H323, mais que penser des rédacteurs de SIP ? la rfc date de 2002. Il pensaient qu'on aller passer en Ipv6 en claquant des doigts ?

                        • [^] # Re: Incontournable

                          Posté par  . Évalué à 2.

                          Peut-être ...
                          Plus sérieusement, je pense qu'ils ont étudié les solutions, mais qu'aucune n'était satisfaisante ... On est toujours obligé de passer par un intermédiaire quand ya du NAT. Bon après, ils auraient pu effectivement prévoir un mode "dégradé" où c'est possible.

  • # Enfin.

    Posté par  . Évalué à 4.

    - La plupart des options de la ligne de commande de "scp" sont maintenant supportées par "sftp". L'objectif à terme est tout simplement de remplacer "scp" par "sftp". Pour ce faire, et pour homogénéiser les options de ces deux commandes, l'ancienne option peu usitée -P de sftp qui donnait le chemin du serveur sftp devient l'option -D. En effet, cette option -P sert maintenant comme dans scp à fixer le port du serveur.
    J'ai toujours trouvé sftp -o Port=XXX chiant à taper !

    • [^] # Re: Enfin.

      Posté par  . Évalué à 1.

      alias ?

    • [^] # Re: Enfin.

      Posté par  . Évalué à 2.

      Maintenant ce qui est chiant c'est entre ssh et scp/sftp. C'est -p ou -P.

      • [^] # Re: Enfin.

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

        Dans scp, le -p veut dire "preserve" comme pour "cp" et c'est assez logique de le garder ainsi. Il faudrait donc modifier le -p de ssh en -P mais c'est pénible ces options en majuscule...

        Le mieux serait peut être d'avoir dans ssh à la fois -p et -P qui signifieraient la même chose.

  • # Numéros de version ?

    Posté par  . Évalué à 3.

    Vivement la version 6.4 !

    Juste par curiosité, y-a-t-il une raison particulière pour que les versions majeurs soient en .4 ?

  • # scp vs sftp

    Posté par  . Évalué à 4.

    La plupart des options de la ligne de commande de "scp" sont maintenant supportées par "sftp". L'objectif à terme est tout simplement de remplacer "scp" par "sftp".
    C'est quoi les avantages de sftp par rapport à scp ?

    • [^] # Re: scp vs sftp

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

      SCP, c'est un hack sur SSH, qui utilise des trucs style ls et cat pour transférer des fichiers. Ainsi, pour faire du SCP, il faut un shell.

      SFTP, c'est un vrai protocole de transfert et de gestion de fichiers qui utilise SSH comme couche de transport. Donc pas besoin de shell, ça peut utliser un sous-système intégré au serveur SSH, et donc ça se chroote facilement.

    • [^] # Re: scp vs sftp

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

      Essaie de transférer un fichier dont le nom contient un espace, un crochet, n'importe quoi en dehors de [a-z0-9].

      • [^] # Re: scp vs sftp

        Posté par  . Évalué à 4.

        Essaie de transférer un fichier dont le nom contient un espace, un crochet, n'importe quoi en dehors de [a-z0-9].

        Ben ca marche

        $cd /tmp
        $mkdir 1
        $mkdir 2
        $touch 1/"pp pp"
        $scp -P443 1/pp\ pp localhost:/tmp/2
        $ ls -l 2/
        23:12 pp pp

  • # Tout terrain

    Posté par  . Évalué à 1.

    Vraiment super pour tout type de machine que se soit un petit NAS pas cher, un gros serveur ou un poste client, il est vraiment polyvalent.

    Existait-il un système similaire avant (libre ou non) ? Ou ssh est-il le premier (le seule ?) système de se genre ?

Suivre le flux des commentaires

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