Un pas de plus vers la démocratisation du sftp

Posté par  (site web personnel) . Modéré par Bruno Michel.
Étiquettes :
2
22
fév.
2008
OpenBSD
Une nouvelle fonctionnalité se rajoute à OpenSSH : ChrootDirectory. Ainsi, il est facile de chrooter suite à la connexion d'un utilisateur. Cela permet de limiter la vision du système de fichier à un sous-ensemble lorsque cet utilisateur se connecte en ssh.

Combiné au serveur sftp intégré à sshd, il est possible de limiter l'utilisateur à une partie du système de fichier ne possédant aucun binaire, aucune bibliothèque, ni aucun node, comme ça aurait du être le cas si le server sftp n'était pas intégré à sshd. Par exemple, les hébergeurs web pourront maintenant, grâce à cette fonctionnalité, remplacer ftp par sftp. Pour rendre l'accès limité au sftp pour l'utilisateur michu, en supposant que son repertoire de pages web est dans /var/www/users/michu, rajoutez ça à votre /etc/ssh/sshd_config (avec la version CVS d'OpenSSH) :
Match group webuser
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
ChrootDirectory /var/www/users

Il peut également être nécessaire de changer le système sftp par celui inclu dans sshd :
#Subsystem sftp /usr/libexec/sftp-server
Subsystem sftp internal-sftp

Mettez madame michu dans le groupe webuser en groupe principal, et mettez-lui comme home /michu. Faites bien attention aux droits du répertoire /var/www/users/ pour qu'elle n'ait accès qu'à /var/www/users/michu et rien d'autre. Vous pouvez alors mettre ftp à la poubelle.

Petit inconvénient : Madame Michu ne pourra pas utiliser scp, elle sera limité à sftp.

Aller plus loin

  • # Remplacer ? Pas tout à fait

    Posté par  . Évalué à 3.

    Il y a de fortes chances que les hébergeurs Web gardent quand même le FTP, qui reste (hélas ?) le plus grand dénominateur commun.

    Mais pour les geeks en herbe qui administrent leurs machines et pour les entreprises, c'est une excellente nouvelle. Plus de daemon FTP = un process de moins = moins d'administration et de failles potentielles. Surtout que ça pullulait à une certaine époque, les problèmes de sécurité avec les serveurs FTP...

    • [^] # Re: Remplacer ? Pas tout à fait

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

      Plus de FTP, c'est aussi plus de mots de passe en clair…

      • [^] # Re: Remplacer ? Pas tout à fait

        Posté par  . Évalué à 10.

        > Plus de FTP, c'est aussi plus de mots de passe en clair…

        ... et plus de vilains bricolages dans les firewall pour laisser passer le traffic FTP DATA en mode actif et en mode passif.

      • [^] # Re: Remplacer ? Pas tout à fait

        Posté par  . Évalué à 2.

        Pas tout à fait d'accord, il y aura sans doute toujours des mots de passes qu icirculeront en clair.
        Bon, ftp en moins, c'est juste moins de mots de passe en claire, mais i lreste notamment le pop3 qui transite pour bcp de mailer en clair, notamment les mailers des FAI

        • [^] # Re: Remplacer ? Pas tout à fait

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

          Même quand la solution de chiffrement existe, elle n'est pas forcément utilisé. Y a qu'à voir tout les services web qui n'utilisent pas https.

        • [^] # Re: Remplacer ? Pas tout à fait

          Posté par  . Évalué à 2.

          Dans la majeure partie des cas, le mot de passe de pop3 ne quitte pas le réseau du FAI, donc il y a légèrement moins de problème de sniffing (en termes de probabilités).

          • [^] # Re: mots de passe POP3

            Posté par  . Évalué à 1.

            Dans la majeure partie des cas, le mot de passe de pop3 ne quitte pas le réseau du FAI, donc il y a légèrement moins de problème de sniffing (en termes de probabilités).

            pas toujours : j'utilise des adresses mail obtenues il y a longtemps avec des connexions accès libres chez tiscali et wanadoo. L'avantage : je ne perd pas mes adresses lorsque je change de FAI (ça m'est arrivé plusieurs fois depuis mes premiers forfaits 5h en 56k...). J'y accède en POP3 depuis de nombreux réseaux différents : celui de mon labo, le FAI chez moi, le FAI chez mes parents...

            Ça faisait longtemps que ces histoires de mots de passe qui transitent en clair sur les réseaux m'ennuyaient. C'est une des raisons principales qui vont causer ma migration totale vers mon récent compte Gmail : Google permet le POP3S, l'IMAPS (en plus du webmail) : que du bonheur.

    • [^] # Re: Remplacer ? Pas tout à fait

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

      >>> Il y a de fortes chances que les hébergeurs Web gardent quand même le FTP, qui reste (hélas ?) le plus grand dénominateur commun.

      s/plus grand dénominateur commun/plus petit dénominateur commun

    • [^] # Re: Remplacer ? Pas tout à fait

      Posté par  . Évalué à 3.

      Pour les hébergeurs web, je ne sais pas, mais je sais qu'au boulot ça nous permettra de nous simplifier pas mal la tache..

      • [^] # Re: Remplacer ? Pas tout à fait

        Posté par  . Évalué à 3.

        J'ignore si cela vous simplifiera la tache, en tout cas j'espère que cela vous simplifiera la tâche !

        Répète après moi : "Windows est multi-taches, Linux est multi-tâches"

        • [^] # Re: Remplacer ? Pas tout à fait

          Posté par  . Évalué à 1.

          Oupss... Dans mon empressement à poster, j'en ai oublié les liens.
          tache et [[tâche]] bien sûr... Wikipedia nous dit même que "tâche" vient d'une racine latine qui a donné "tasche", et qui se rapproche de "task" en anglais. Du coup, plus de raisons de faire l'erreur (mais je préfère ma phrase mnémotechnique quand même :-p )


          Wiktionnary[1] nous donne même une étymologie


          1 http://fr.wiktionary.org/wiki/tache

    • [^] # Re: Remplacer ? Pas tout à fait

      Posté par  . Évalué à -4.

      Je ne comprends pas très bien. Faire passer du ftp dans un tunnel ssl ça n'a rien de neuf, là ça n'apporte qu'une simplification de la méthode.

      Mais sérieusement intégrer ftp dans le démon ssh ça me chagrine légèrement. Ça fait une appli plus grosse, plus compliquée à maintenir, etc Moi qui croyait qu'unix voulais des appli petites et flexible.

      Là ça fait un peu usine à gaz, même si c'est léger à l'exécution.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # C'est déja possible avec scponly

    Posté par  . Évalué à 4.

    Il y a une "extention" qui est en fait un shell, elle permet de forcer les utilisateurs à ne faire que du scp ou du sftp, mais aussi de créer des chroot (avec juste ce qu'il faut de binaire pour que scponly fonctionne).
    Voir http://sublimation.org/scponly/wiki/index.php/Main_Page pour plus d'information.
    Je l'utilise pas mal car j'aime pas donner des shells a qui doit juste deposer/effacer/... des fichiers dans les répertoire applicatifs des serveurs.

    Tant mieux si cette fonctionnalité est directement intégrée a OpenSSH, ce sera plus propre.

    • [^] # Re: C'est déja possible avec scponly

      Posté par  . Évalué à 5.

      C'est exactement pour remplacer ce genre de hack, plus ou moins maison, plus ou moins propre (pour te citer), que cette fonctionnalité vient d'être ajoutée :) enjoy !

    • [^] # Re: C'est déja possible avec scponly

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

      LA différence avec scponly ou rssh, c'est que tu n'as pas besoin de maintenir les binaires du chroot, mise à jours de sécurité, etc car ils ne sont pas requis.

  • # excellente nouvelle

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

    C'est juste une excellente nouvelle :-)

  • # Je commence à être perdu...

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

    SFTP (SSH FTP)
    SFTP (Secure FTP)
    FTPS (FTP over SSL)
    Je commence à être perdu moi!

    Quel est l'avantage de SFTP par rapport à FTPS?
    Pour moi, un FTP sécurisé existait déjà, et ce n'est pas cette modification qui va changer la non-volonté des gens à passer à du secure, pourquoi cet optimisme?

    Et ca commence à me faire bizarre de tout faire passer par SSH...
    Pour moi, une appli une fonction SSH pour l'accès, et FTP(S) pour les transferts...

    Et si je comprend bien la présentation (n'hésitez pas à me corriger!), si je configure pour avoir du SFTP chrooté pour mes "clients", je ne pourrai plus faire de scp? Ou tout le monde n'est pas logé à la même enseigne et on peut chrooter à la tête du login?

    PS : sinon, une première page pour un commit CVS, ca fait pas un peu beaucoup?

    • [^] # Re: Je commence à être perdu...

      Posté par  . Évalué à 5.

      SFTP (le truc over SSH dont on parle dans le journal) a l'avantage de ne pas nécessiter d'autre logiciel côté serveur que le sshd.
      FTPS et ses innombrables variantes (FTP via SSL, FTP via TLS explicite/implicite) sont simplement une manière de faire passer les commandes FTP classiques dans une connexion chiffrée (la distinction se faisant sur la version de l'infrastructure de chiffrement utilisée, ainsi que sur le port par défaut).

      Jusqu'ici, j'ai toujours un peu vu SCP/SFTP comme un "FTP du pauvre". Super pratique parce qu'installé par défaut partout où on a un shell, mais clairement pas les mêmes taux de transferts qu'un FTP. C'est pratique pour uploader un fichier de configuration, nettement moins pour récupérer une sauvegarde intégrale d'un système.

      FTPS, je m'en sert essentiellement pour fournir de l'espace de stockage "sécurisé" à des tiers, et limiter d'autant l'envoi de grosses pièces jointes par mail sans toutefois imposer de mettre des trucs confidentiels sur dl.free.fr ou rapidshare (ou pire: une page perso Free).

      L'autre grande différence, c'est que SFTP s'appuie sur OpenSSH (et donc le partage de clé qui va avec), tandis que FTPS s'appuie sur X509 (et donc une hiérarchie de certificats chapeautés par une autorité toute puissante).

    • [^] # Re: Je commence à être perdu...

      Posté par  . Évalué à 6.

      FTP over SSL (ou TLS, c'est presque pareil) a un énorme inconvénient : ca rend le firewalling extremement délicat. Je m'explique : si on chiffre le canal de controle de facon a ne pas faire passer le mot de passe en clair, comment faire pour que les firewalls qui se trouvent sur le chemin traquent et ouvrent le port (aléatoire) qui va etre négocié et utilisé pour le transfert des données ? De plus, FTPS ne chiffre pas toujours (ca dépend des implémentations...) le canal de données.

      Le problème de FTP est que c'est un protocole complètement inadapté à la sécurité des réseaux moderne. SFTP fonctionnant sur un seul port me semble répondre plutot bien a ce besoin.

      • [^] # Re: Je commence à être perdu...

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

        Ce n'est pas si compliqué que cela : Certains serveur FTP/FTPS ont une option permettant d'ouvrir les ports de DONNEES uniquement sur une certaine plage. Il suffit alors de laisser un "trou" dans le firewall pour laisser rentrer les connexions sur ces ports-là.

        Coté client, il ne faut se connecter qu'en mode PASSIF, car en mode ACTIF, le firewall du CLIENT ne laissera rien passer.

        Pour PROFTPD, c'est l'option "PassivePorts 45000 45100" qui permet de n'ouvrir les ports de 45000 à 45100 en mode PASSIF.

        J'utilise cette technique depuis des années sur mes serveurs FTP+TLS

        • [^] # Re: Je commence à être perdu...

          Posté par  . Évalué à 3.

          Il suffit alors de laisser un "trou" dans le firewall pour laisser rentrer les connexions sur ces ports-là.
          Ce qui n'est pas propre : tu laisse ouvert de ports qui vont renvoyer un RST, et qui n'ont pas besoin normalement d'être ouvert.
          Bref, : berk!

          • [^] # Re: Je commence à être perdu...

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

            Ce qui n'est pas propre : tu laisse ouvert de ports qui vont renvoyer un RST, et qui n'ont pas besoin normalement d'être ouvert.
            Quel est le problème ? C'est que ta machine n'est plus un "trou noir" sur Internet ? De toute façon, il est déjà visible, car tu as laissé le port FTPS d'ouvert

            Tu crains une attaque par DoS sur ces ports là ? Netfilter peut limiter ses réponses avec le paramètre "--limit"

            Si tu as une meilleur solution, je suis preneur. Mais netfilter n'ayant aucun moyen de décoder le flux de commande, il n'y a pas moyen de faire autrement.

            • [^] # Re: Je commence à être perdu...

              Posté par  . Évalué à 2.

              Mais netfilter n'ayant aucun moyen de décoder le flux de commande, il n'y a pas moyen de faire autrement.
              J'ai pas dis qu'il n'y de moyen, j'ai dis que ce n'était pas propre (ie que le protocole est merdique et pas vraiment firewall friendly).

              En réalité il y a bien une solution, c'est d'avoir une authentification par certificat, et d'avoir la clée privée du serveur dupliquée sur le fw, pour qu'il puisse lire les flux. C'est déjà utilisé par certains équipements de monitoring pour le https ce genre de solutions.

    • [^] # Re: Je commence à être perdu...

      Posté par  . Évalué à 2.

      >PS : sinon, une première page pour un commit CVS, ca fait pas un peu beaucoup?

      Vu le nombre de remarque, visiblement ce n'est pas le cas!

      Sinon pour répondre a ta question, le gros interet de pouvoir faire la même chose avec SFTP qu'avec FTP, c'est que ça va simplifier les choses: plus de serveur FTP qui fait doublon avec le serveur SFTP/SSH, plus de double gestion des comptes, simplification de la configuration du firewall..

      Et j'ajouterai aussi: plus de problème lié a un client FTP en mode ASCII (quelle c... cette fonctionnalité!).

      Donc clairement: a sab FTP, eviv SFTP.

    • [^] # Re: Je commence à être perdu...

      Posté par  . Évalué à 2.

      L'avantage est d'avoir un seul serveur, un seul port à ouvrir...
      Et SSH va très au delà de la possibilité de s'ouvrir un shell distant:
      -Forward de ports via tunnels, pour sécuriser des applis pas sécurisées à la base (en association avec le firewall qui bloque les connections directes au service): VNC en est un exemple courant.
      -Tunnels dynamiques=un proxy socks qui permet de faire passer toutes les connections sous SSH des applis supportant cette config (extrèmement courant: navigateurs web, clients mail...), ou de toute appli ne le prévoyant pas mais lancée via tsocks: Utile pour contourner les filtrages WEB des entreprises (via sa propre connection ADSL perso). Parfois, il faut combiner avec une appli de connect proxy et faire écouter le daemon ssh sur le port 443 en plus du 22 afin de faire croire au proxy/firewall qu'on fait du HTTPS ;o), mais c'est chez les + paranos!
      -Reverse tunnels: Encore plus fort: On peut littérallement bypasser la necessité du VPN pour se connecter de l'extérieur sur tout intranet.
      -SCP pour copier des fichiers sécurisés (sur un lien fiable: pas de reprise comme en FTP).
      -SFTP pour faire la même chose sur un lien moins fiable/s'interfacer avec la plupart des clients FTP et ne pas modifier les habitudes des utilisateurs.

      Bref, SSH c'est vraiment top. Je ne sais même pas comment je bosserait dans ma boite si ses multiples finesses ne me permettaient pas de bypasser toutes les limitations/firewalls débiles entre les sous-réseaux de la boite. C'est tellement bien, que ça a prévu les admins cons!

  • # Plus précisément

    Posté par  . Évalué à 3.

    Serait-il possible d'attribuer un répertoire d'accueil pour chaque user ?
    Je veux dire que là, michu est chrooté dans /var/www/users, et donc il "voit" les autres répertoires, et doit rentrer dans le sien. Même si les droits sont mis en place pour qu'il ne puisse pas rentrer dans les autres répertoires, il les voit.

    Y a t-il une possibilité de chroot unique pour un user, ou alors est-ce une feature qui sera fait dans l'avenir/jamais ?

    • [^] # Re: Plus précisément

      Posté par  . Évalué à 6.

      > les autres répertoires, et doit rentrer dans le sien.

      Non, au login sftp va placer l'utilisateur directement dans /chroot/$HOME/

      > Même si les droits sont mis en place pour qu'il ne puisse pas
      > rentrer dans les autres répertoires, il les voit.

      Voila une astuce simple décrite sur Undeadly, pour éviter que
      les utilisateurs ne voient les autres homes :

      1) Modifier l'indication des chemins des répertoires home
      dans /etc/passwd pour qu'ils ressemblent à : /user1, /user2, ...

      2) Créer cette structure de répertoires :
      /chroot/user1/user1
      /chroot/user2/user2

      3) Puis, dans ssh_config :
      Match Group sftpusers
      
    ChrootDirectory /chroot/%u
      
    ForceCommand internal-sftp


      Et hop, c'est réglé, l'utilisateur ne voit pas les autres homes, seulement la sienne.

      • [^] # Re: Plus précisément

        Posté par  . Évalué à 1.

        Il y a aussi une autre méthode, non ?
        Ca peut fonctionner de faire plusieurs directives "Match Group". Comme ça, si chaque user à un GID unique, on peut le chrooter ailleurs.
        A voir si ça peut marcher, et si ça peut être mieux...

        • [^] # Re: Plus précisément

          Posté par  . Évalué à 2.

          Oui, bien entendu. Le but de l'exemple était d'éviter de faire une entrée par utilisateur.

          Si on est prêt à faire une entrée dans sshd_config par utilisateur, alors Match User convient aussi bien (dans ce cas, il n'est pas nécessaire que les utilisateurs aient des gid uniques).

          • [^] # Re: Plus précisément

            Posté par  . Évalué à 1.

            Ah ben oui, encore mieux Match User comme directive.
            Merci beaucoup.

    • [^] # Re: Plus précisément

      Posté par  . Évalué à 1.

      l'utilisateur se connecte dans le répertoire /var/www/users/son_login mais il apparait comme racine / pour lui. Il lui est impossible de remonter pour voir les autres répertoires.

      • [^] # Re: Plus précisément

        Posté par  . Évalué à 6.

        > l'utilisateur se connecte dans le répertoire /var/www/users/son_login mais il apparait comme racine / pour lui.

        Non, sftp va se chrooter dans ChrootDir, puis va faire un chdir() dans la home de l'user (telle qu'indiquée dans /etc/passwd, mais relative à la chroot).

        Autrement dit, si la home de toto indiquée dans /etc/passwd est "/home/toto", que le ChrootDir indiqué dans sshd_config est est "/chroot", alors sftp :
        1- se chrootera dans /chroot
        2- puis se déplacera dans /home/toto, relativement à sa chroot (donc en vrai, dans /chroot/home/toto).
        3- l'utilisateur toto pourra voir les répertoires contigus à sa home (c'est à dire tout ceux en dessous du répertoire /chroot, y compris /chroot/home/pouet/, s'il existe).

        Ce qui me fait penser, au passage et pour compléter la réponse que j'ai donné juste au-dessus, que si on veux garder une arborescence des homes du type /home/user1, /home/user2, alors on doit pouvoir faire :

        Match Group sftpusers
        
    ChrootDirectory /home/%u
        
    ForceCommand internal-sftp


        Et dans /etc/passwd, indiquer "/" comme path de toutes les homes des utilisateurs qu'on veut chrooter.

  • # Utilité de FTP ?

    Posté par  . Évalué à 5.

    Je me demande à quoi peut bien encore servir FTP aujourd'hui, alors que le protocole est tellement mal fichu qu'il était déjà quasiment obsolète lors de sa conception... Pourquoi continuer de se le coltiner ?

    La seule raison que je connaisse, c'est que comme il y a moins de bande passante réservée aux contrôles, le taux de téléchargement peut être un peu supérieur (au prix d'un risque d'erreurs plus élevé).

    On peut très bien télécharger via HTTP, gérer ses données aussi avec les extensions WebDav, on a SSH et SFTP, on a Bittorrent... Que reste-t-il au vilain petit canard ?

    • [^] # Re: Utilité de FTP ?

      Posté par  . Évalué à 2.

      Au hasard:
      Le fait que tous les FAI ne proposent que ce protocole pour uploader les données de "monsieurs Michu" et qui donc s'orientent et préfèreront ce protocole si un jour ils ont à en mettre un en place (habitudes toussa .. )



      [Halte à la dictature de madame Michu, elle n'est pas plus bête que monsieur Michu]

    • [^] # Re: Utilité de FTP ?

      Posté par  . Évalué à 2.

      Tu oubli FXP dans l'utilité du canal de contrôle. Et c'est aujourd'hui encore pas mal utilisé.

      Concernant ton histoire de bande passante supérieure et de risque d'erreurs, c'est un problème qui est quand même réglé depuis très très longtemps... FTP est un protocole qui fonctionne bien avec un problème de sécurité résolu par SSL.

      D'autre part, tout faire passer par HTTP me pose un énorme problème : quid de la maîtrise des flux ? HTTP, c'est pour HyperText, donc du texte. Je ne vois pas ce que le fait de télécharger un binaire à quelque chose à faire avec HTTP... Mais bon, il parait que c'est à la mode de faire des protocoles applicatifs sur un protocole déjà applicatif... C'est pas comme si HTTP était lourd...

      Pour finir, SFTP c'est très bien, mais ça ne fonctionne qu'avec des machines ayant SSH, ce qui est loin d'être le cas de tout serveur (en particulier ceux dont tu n'as pas complètement la main)

      • [^] # Re: Utilité de FTP ?

        Posté par  . Évalué à 2.

        > Tu oubli FXP dans l'utilité du canal de contrôle.

        Et, à part la dimension tartufesque de ftp (et le risque sécurité bien connu de cette fonctionnalité de ftp, la fameuse "FTP bounce attack"), quel est l'intérêt de FXP par rapport à un simple :
        scp user1@server1.com:/truc user2@server2.com:/chose ?

  • # Utilisable depuis longtemps grace à un patch

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

    Avec le patch http://chrootssh.sourceforge.net/index.php , il est faisable depuis longtemps d'enfermer un utilisateur SSH ou SFTP dans un chroot.

    Le patch ne fait que quelques lignes, et il il suffisait de déclarer le chroot dans le /etc/passwd :

    ftpuser:1010:1010:FTP anonymous account,,,:/var/chroot/ftpuser/./:/bin/sh

    C'est le "./" à la fin du paramètre "HOME" du /etc/passwd qui déclenche l'utilisation du chroot par SSH.

    J'ai utilisé cette technique pendant longtemps sur mes serveurs SSH/SFTP, avant de passer en FTPS (ProFTPD+TLS)

    • [^] # Re: Utilisable depuis longtemps grace à un patch

      Posté par  . Évalué à 1.

      proFTPd, c'est pas un progrès comparé à SSH. Le seul pb de SFTP, je trouve, c'est le taux de transfert en berne. Par contre, entre SCP et un FTP classique, y'a pas bcp de perte.

      C'est pourquoi il est assez dommage que SCP ne soit pas ainsi chrootable: J'observe généralement 25/30% de taux de transfert en moins via SFTP comparé à SCP. Ceci essayé avec les 2 clients windows classiques (filezilla et winscp) utilisé par ceux qui se connectent chez moi et qui permettent de faire du scp ou du tftp.

      Mais bon, c'est quand même un beau progrès, surtout que tftp s'en sort tout de même mieux sur les liens peu fiables avec ses possibilités de reprise.

Suivre le flux des commentaires

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