samedi 26 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

: Un pas de plus vers la démocratisation du sftp

Posté par TeXitoi (Jabber id, page perso, ). Modéré le 22 février 2008.
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.

> Lire la dépêche (51 commentaires, moyenne: 2,9).  

Vous avez demandé le commentaire #908031.

Je commence à être perdu...

Posté par Zenitram (page perso, ) le 22/02/2008 à 20:49. (lien). É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 Larry Cow () le 22/02/2008 à 21:47. (lien). É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 phyce () le 22/02/2008 à 23:30. (lien). É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 Olivier (page perso, ) le 23/02/2008 à 18:27. (lien). É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 briaeros007 () le 25/02/2008 à 20:50. (lien). É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!

        --
        Subete ga wakatta toki…watashi ga anta wo korosu.

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

          Posté par Olivier (page perso, ) le 26/02/2008 à 11:36. (lien). É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 briaeros007 () le 27/02/2008 à 07:11. (lien). É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.

            --
            Subete ga wakatta toki…watashi ga anta wo korosu.

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

    Posté par reno () le 23/02/2008 à 16:06. (lien). É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 Larry Cow () le 23/02/2008 à 18:48. (lien). Évalué à 3.

      A sab PTF, eviv PTFS, elicébmi :)

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

    Posté par yvan () le 28/02/2008 à 16:33. (lien). É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!

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0643s (dont 0.0067 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.