Pour des échanges de documents avec quelques correspondants, j'ai installé
pure-ftpd sur mon pc. J'ai créé les utilisateurs virtuels en suivant les
indications de Léa :
http://www.lea-linux.org/documentations/index.php/Reseau-partfic-pureftpd
En local, tout fonctionne parfaitement. (Client en mode actif.)
Malheureusement, plusieurs correspondants se plaignent de ne pouvoir se
connecter ou, plus exactement, de ne pas obtenir la liste des fichiers de
leur répertoire. Je me demande donc si les règles de NAT que j'ai créées
dans mon modem-routeur sont correctes. Tel que je l'ai configuré, le serveur
propose pour les données un port dans la plage 30000-30199. (Mode passif)
Règle NAT créée au bénéfice de mon poste dont l'ip locale est fixe :
Le 25/05/2011 06:33, Pascal Hambourg nous fit lire :
geo cherchetout a écrit :
Une dernière question quand-même : Cette formule de FTP over SSH vous semble-t-elle convenable ? https://wiki.archlinux.org/index.php/SFTP
SFTP est un protocole de transfert de fichier sur SSH, ce n'est pas du FTP sur SSH. Il a pour avantage d'être sécurisé et plus facile à NATer que FTP ou sa variante sécurisé FTPS (pour lequel la prise en charge FTP du routeur est inopérante) puisqu'il n'implique qu'une seule connexion TCP sur un port fixe. Par contre il faut un client qui le gère comme Filezilla, et par défaut SSH accorde un accès shell au serveur qu'il faut désactiver si on n'en veut pas.
Néanmoins, il existe une possibilité de faire du FTP sur SSH (avec du vrai SSH et du vrai FTP)... un industriel l'a fait et j'en sais quelque chose.
Il faut le client qui va bien (c'est un rien subtile), mais du coté serveur, c'est 100% standard: il suffit d'autoriser le port-forwarding de SSH (ce qui n'est pas souvent le cas par défaut), en se limitant sur 127.0.0.1 pour les adresses destinations autorisés; (ou alors bonjour l'usine a botnet si on ne bride pas)
Le client ouvre une session SSH, puis avec le port-forwarding, ouvre la connexion sur le port 21. (donc ça fout en l'air les log du serveur FTP pour la sécurité, il faut consulter les log du serveur SSH!).
Les transferts doivent se faire dans le mode alternatif au mode FTP par défaut de la RFC, puisque le client va refaire un port forwarding sur le serveur.
Le 25/05/2011 06:33, Pascal Hambourg nous fit lire :
geo cherchetout a écrit :
Une dernière question quand-même : Cette formule de FTP over SSH vous
semble-t-elle convenable ? https://wiki.archlinux.org/index.php/SFTP
SFTP est un protocole de transfert de fichier sur SSH, ce n'est pas du
FTP sur SSH. Il a pour avantage d'être sécurisé et plus facile à NATer
que FTP ou sa variante sécurisé FTPS (pour lequel la prise en charge FTP
du routeur est inopérante) puisqu'il n'implique qu'une seule connexion
TCP sur un port fixe. Par contre il faut un client qui le gère comme
Filezilla, et par défaut SSH accorde un accès shell au serveur qu'il
faut désactiver si on n'en veut pas.
Néanmoins, il existe une possibilité de faire du FTP sur SSH (avec du
vrai SSH et du vrai FTP)... un industriel l'a fait et j'en sais quelque
chose.
Il faut le client qui va bien (c'est un rien subtile), mais du coté
serveur, c'est 100% standard: il suffit d'autoriser le port-forwarding
de SSH (ce qui n'est pas souvent le cas par défaut), en se limitant sur
127.0.0.1 pour les adresses destinations autorisés; (ou alors bonjour
l'usine a botnet si on ne bride pas)
Le client ouvre une session SSH, puis avec le port-forwarding, ouvre la
connexion sur le port 21. (donc ça fout en l'air les log du serveur FTP
pour la sécurité, il faut consulter les log du serveur SSH!).
Les transferts doivent se faire dans le mode alternatif au mode FTP par
défaut de la RFC, puisque le client va refaire un port forwarding sur le
serveur.
Le 25/05/2011 06:33, Pascal Hambourg nous fit lire :
geo cherchetout a écrit :
Une dernière question quand-même : Cette formule de FTP over SSH vous semble-t-elle convenable ? https://wiki.archlinux.org/index.php/SFTP
SFTP est un protocole de transfert de fichier sur SSH, ce n'est pas du FTP sur SSH. Il a pour avantage d'être sécurisé et plus facile à NATer que FTP ou sa variante sécurisé FTPS (pour lequel la prise en charge FTP du routeur est inopérante) puisqu'il n'implique qu'une seule connexion TCP sur un port fixe. Par contre il faut un client qui le gère comme Filezilla, et par défaut SSH accorde un accès shell au serveur qu'il faut désactiver si on n'en veut pas.
Néanmoins, il existe une possibilité de faire du FTP sur SSH (avec du vrai SSH et du vrai FTP)... un industriel l'a fait et j'en sais quelque chose.
Il faut le client qui va bien (c'est un rien subtile), mais du coté serveur, c'est 100% standard: il suffit d'autoriser le port-forwarding de SSH (ce qui n'est pas souvent le cas par défaut), en se limitant sur 127.0.0.1 pour les adresses destinations autorisés; (ou alors bonjour l'usine a botnet si on ne bride pas)
Le client ouvre une session SSH, puis avec le port-forwarding, ouvre la connexion sur le port 21. (donc ça fout en l'air les log du serveur FTP pour la sécurité, il faut consulter les log du serveur SSH!).
Les transferts doivent se faire dans le mode alternatif au mode FTP par défaut de la RFC, puisque le client va refaire un port forwarding sur le serveur.
Nicolas George
Le Forgeron , dans le message <4de10685$0$7165$, a écrit :
Nicolas George se trompe d'ennemi:
Non.
c'est IPv4+Nat qu'il faut mettre à la décharge!
Oui. Mais FTP, c'est quand même de la merde.
Le Forgeron , dans le message <4de10685$0$7165$426a34cc@news.free.fr>, a
écrit :
Nicolas George se trompe d'ennemi: c'est IPv4+Nat qu'il faut mettre à la décharge! (avec une compagnie de CRS à demeure pour l'empêcher d'en resortir)
Cépafo.
Mais même sans NAT, j'en ai eu plusieurs, c'est pain in the ass pour configurer le firewall, si on veut du mode actif. En passif, no problem.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Pascal Hambourg
Xavier a écrit :
Mais même sans NAT, j'en ai eu plusieurs, c'est pain in the ass pour configurer le firewall, si on veut du mode actif. En passif, no problem.
Ça dépend de quel côté on se place, client ou serveur. C'est symétrique. Les problèmes en mode passif se produisent plutôt côté serveur, alors que les problèmes en mode actif sont plutôt côté client. Du côté des connexions de données entrantes, en fait.
Xavier a écrit :
Mais même sans NAT, j'en ai eu plusieurs, c'est pain in the ass pour
configurer le firewall, si on veut du mode actif. En passif, no problem.
Ça dépend de quel côté on se place, client ou serveur. C'est symétrique.
Les problèmes en mode passif se produisent plutôt côté serveur, alors
que les problèmes en mode actif sont plutôt côté client. Du côté des
connexions de données entrantes, en fait.
Mais même sans NAT, j'en ai eu plusieurs, c'est pain in the ass pour configurer le firewall, si on veut du mode actif. En passif, no problem.
Ça dépend de quel côté on se place, client ou serveur. C'est symétrique. Les problèmes en mode passif se produisent plutôt côté serveur, alors que les problèmes en mode actif sont plutôt côté client. Du côté des connexions de données entrantes, en fait.
Pascal Hambourg
Nicolas George a écrit :
Le Forgeron a écrit :
c'est IPv4+Nat qu'il faut mettre à la décharge!
Le NAT, certainement. IPv4, je ne trouve pas, du moins dans les contextes ou le NAT n'est pas nécessaire. Sinon on peut aller plus loin en disant qu'il faudrait aussi balancer TCP au profit de SCTP.
Oui. Mais FTP, c'est quand même de la merde.
Son fonctionnement n'est plus adapté à l'internet actuel, plein de NAT et de firewalls. Mais je trouve que la séparation du canal de commande et du canal de données est une bonne idée. Avec un transport SCTP au lieu de TCP il serait possible de conserver cette séparation sur une même connexion.
Nicolas George a écrit :
Le Forgeron a écrit :
c'est IPv4+Nat qu'il faut mettre à la décharge!
Le NAT, certainement. IPv4, je ne trouve pas, du moins dans les
contextes ou le NAT n'est pas nécessaire.
Sinon on peut aller plus loin en disant qu'il faudrait aussi balancer
TCP au profit de SCTP.
Oui. Mais FTP, c'est quand même de la merde.
Son fonctionnement n'est plus adapté à l'internet actuel, plein de NAT
et de firewalls. Mais je trouve que la séparation du canal de commande
et du canal de données est une bonne idée. Avec un transport SCTP au
lieu de TCP il serait possible de conserver cette séparation sur une
même connexion.
Le NAT, certainement. IPv4, je ne trouve pas, du moins dans les contextes ou le NAT n'est pas nécessaire. Sinon on peut aller plus loin en disant qu'il faudrait aussi balancer TCP au profit de SCTP.
Oui. Mais FTP, c'est quand même de la merde.
Son fonctionnement n'est plus adapté à l'internet actuel, plein de NAT et de firewalls. Mais je trouve que la séparation du canal de commande et du canal de données est une bonne idée. Avec un transport SCTP au lieu de TCP il serait possible de conserver cette séparation sur une même connexion.
Nicolas George
Pascal Hambourg , dans le message <iru0gf$1mp$, a écrit :
Son fonctionnement n'est plus adapté à l'internet actuel, plein de NAT et de firewalls.
Pas que. Le fait que le format d'un listing de répertoire ne soit pas spécifié, par exemple, suffit à lui faire mériter la poubelle sans autre forme de procès.
Mais je trouve que la séparation du canal de commande et du canal de données est une bonne idée.
Bof, je ne vois vraiment pas l'intérêt.
Avec un transport SCTP au lieu de TCP il serait possible de conserver cette séparation sur une même connexion.
Il y a quelques années, j'étais très enthousiaste à propos de SCTP, mais plus maintenant : tellement d'API, d'outils, etc., sont conçus avec comme idée de base un flux unique et interrompu d'octets que je pense que c'est une mauvaise idée de bâtir quoi que ce soit au dessus d'autre chose.
Pascal Hambourg , dans le message <iru0gf$1mp$1@saria.nerim.net>, a
écrit :
Son fonctionnement n'est plus adapté à l'internet actuel, plein de NAT
et de firewalls.
Pas que. Le fait que le format d'un listing de répertoire ne soit pas
spécifié, par exemple, suffit à lui faire mériter la poubelle sans autre
forme de procès.
Mais je trouve que la séparation du canal de commande
et du canal de données est une bonne idée.
Bof, je ne vois vraiment pas l'intérêt.
Avec un transport SCTP au
lieu de TCP il serait possible de conserver cette séparation sur une
même connexion.
Il y a quelques années, j'étais très enthousiaste à propos de SCTP, mais
plus maintenant : tellement d'API, d'outils, etc., sont conçus avec comme
idée de base un flux unique et interrompu d'octets que je pense que c'est
une mauvaise idée de bâtir quoi que ce soit au dessus d'autre chose.
Pascal Hambourg , dans le message <iru0gf$1mp$, a écrit :
Son fonctionnement n'est plus adapté à l'internet actuel, plein de NAT et de firewalls.
Pas que. Le fait que le format d'un listing de répertoire ne soit pas spécifié, par exemple, suffit à lui faire mériter la poubelle sans autre forme de procès.
Mais je trouve que la séparation du canal de commande et du canal de données est une bonne idée.
Bof, je ne vois vraiment pas l'intérêt.
Avec un transport SCTP au lieu de TCP il serait possible de conserver cette séparation sur une même connexion.
Il y a quelques années, j'étais très enthousiaste à propos de SCTP, mais plus maintenant : tellement d'API, d'outils, etc., sont conçus avec comme idée de base un flux unique et interrompu d'octets que je pense que c'est une mauvaise idée de bâtir quoi que ce soit au dessus d'autre chose.
