j'envisage de créer un compte FTP sur ma machine personnelle pour mettre
à disposition de mes étudiants certains documents, mais je n'ai pas
envie qu'ils puissent se ballader n'importe où.
Premier point : je dois apparemment leur créer un compte utilisateur
ordinaire. Exact ou peut-on créer des comptes "ftp seul" ?
J'ai configuré les fichiers /etc/ftpchroot et /etc/ftpd.conf pour les
mettre en mode "chroot" (c'est bien comme ça qu'on dit ?). La connexion
aboutit alors à un répertoire bien précis, vu comme la racine. De plus,
ce répertoire n'a que des droits de lecture pour ce compte "étudiants".
Par ailleurs, j'ai activé pour mes besoins personnels la connexion ssh.
J'ai donc ajouté une ligne "DenyUsers" concernant ce fameux compte. Ça
bloque bien apparemment la connexion ssh.
Questions : m'y suis-je bien pris, le blindage vous paraît-il suffisant
et, accessoirement, puis-je supprimer le répertoire "home" qui s'est
créé avec le compte, puisqu'il ne sert à rien ?
Merci.
--
Michel Henri (enlever les quatre lettres de fin d'alphabet pour me répondre)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
laurent.pertois
Michel Henri wrote:
j'envisage de créer un compte FTP sur ma machine personnelle pour mettre à disposition de mes étudiants certains documents, mais je n'ai pas envie qu'ils puissent se ballader n'importe où.
Bonne idée.
Premier point : je dois apparemment leur créer un compte utilisateur ordinaire. Exact ou peut-on créer des comptes "ftp seul" ?
Tu pourrais créer un compte qui ne ferait que du FTP mais bon, c'est plus compliqué, en fait.
J'ai configuré les fichiers /etc/ftpchroot et /etc/ftpd.conf pour les mettre en mode "chroot" (c'est bien comme ça qu'on dit ?). La connexion aboutit alors à un répertoire bien précis, vu comme la racine. De plus, ce répertoire n'a que des droits de lecture pour ce compte "étudiants".
Tu as modifié quoi dans le ftpd.conf ? Perso, quand je veux faire ce que tu décris, je fais un utilisateur, ensuite, je me donne des droits plus importants sur le dossier départ (cet utilisateur ne sera utilisé qu'en FTP), je le vide des dossiers par défaut de Mac OS X, je définis les autorisations d'accès et ça me suffit. Je modifie uniquement le /etc/ftpchroot en ajoutant le nom abrégé de cet utilisateur et il est bien cantonné à son dossier perso.
Par ailleurs, j'ai activé pour mes besoins personnels la connexion ssh. J'ai donc ajouté une ligne "DenyUsers" concernant ce fameux compte. Ça bloque bien apparemment la connexion ssh.
Bonne idée, perso, plutôt que de faire du denyuser je n'autorise que certains comptes, ça évite les oublis.
Questions : m'y suis-je bien pris, le blindage vous paraît-il suffisant et, accessoirement, puis-je supprimer le répertoire "home" qui s'est créé avec le compte, puisqu'il ne sert à rien ?
Si tu as tout mis ailleurs, oui, tu peux jeter.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Michel Henri <m_hewxynri@club-intzzzernet.fr.invalid> wrote:
j'envisage de créer un compte FTP sur ma machine personnelle pour mettre
à disposition de mes étudiants certains documents, mais je n'ai pas
envie qu'ils puissent se ballader n'importe où.
Bonne idée.
Premier point : je dois apparemment leur créer un compte utilisateur
ordinaire. Exact ou peut-on créer des comptes "ftp seul" ?
Tu pourrais créer un compte qui ne ferait que du FTP mais bon, c'est
plus compliqué, en fait.
J'ai configuré les fichiers /etc/ftpchroot et /etc/ftpd.conf pour les
mettre en mode "chroot" (c'est bien comme ça qu'on dit ?). La connexion
aboutit alors à un répertoire bien précis, vu comme la racine. De plus,
ce répertoire n'a que des droits de lecture pour ce compte "étudiants".
Tu as modifié quoi dans le ftpd.conf ? Perso, quand je veux faire ce que
tu décris, je fais un utilisateur, ensuite, je me donne des droits plus
importants sur le dossier départ (cet utilisateur ne sera utilisé qu'en
FTP), je le vide des dossiers par défaut de Mac OS X, je définis les
autorisations d'accès et ça me suffit. Je modifie uniquement le
/etc/ftpchroot en ajoutant le nom abrégé de cet utilisateur et il est
bien cantonné à son dossier perso.
Par ailleurs, j'ai activé pour mes besoins personnels la connexion ssh.
J'ai donc ajouté une ligne "DenyUsers" concernant ce fameux compte. Ça
bloque bien apparemment la connexion ssh.
Bonne idée, perso, plutôt que de faire du denyuser je n'autorise que
certains comptes, ça évite les oublis.
Questions : m'y suis-je bien pris, le blindage vous paraît-il suffisant
et, accessoirement, puis-je supprimer le répertoire "home" qui s'est
créé avec le compte, puisqu'il ne sert à rien ?
Si tu as tout mis ailleurs, oui, tu peux jeter.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
j'envisage de créer un compte FTP sur ma machine personnelle pour mettre à disposition de mes étudiants certains documents, mais je n'ai pas envie qu'ils puissent se ballader n'importe où.
Bonne idée.
Premier point : je dois apparemment leur créer un compte utilisateur ordinaire. Exact ou peut-on créer des comptes "ftp seul" ?
Tu pourrais créer un compte qui ne ferait que du FTP mais bon, c'est plus compliqué, en fait.
J'ai configuré les fichiers /etc/ftpchroot et /etc/ftpd.conf pour les mettre en mode "chroot" (c'est bien comme ça qu'on dit ?). La connexion aboutit alors à un répertoire bien précis, vu comme la racine. De plus, ce répertoire n'a que des droits de lecture pour ce compte "étudiants".
Tu as modifié quoi dans le ftpd.conf ? Perso, quand je veux faire ce que tu décris, je fais un utilisateur, ensuite, je me donne des droits plus importants sur le dossier départ (cet utilisateur ne sera utilisé qu'en FTP), je le vide des dossiers par défaut de Mac OS X, je définis les autorisations d'accès et ça me suffit. Je modifie uniquement le /etc/ftpchroot en ajoutant le nom abrégé de cet utilisateur et il est bien cantonné à son dossier perso.
Par ailleurs, j'ai activé pour mes besoins personnels la connexion ssh. J'ai donc ajouté une ligne "DenyUsers" concernant ce fameux compte. Ça bloque bien apparemment la connexion ssh.
Bonne idée, perso, plutôt que de faire du denyuser je n'autorise que certains comptes, ça évite les oublis.
Questions : m'y suis-je bien pris, le blindage vous paraît-il suffisant et, accessoirement, puis-je supprimer le répertoire "home" qui s'est créé avec le compte, puisqu'il ne sert à rien ?
Si tu as tout mis ailleurs, oui, tu peux jeter.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ patrick proniewski
In article , Matt wrote:
Questions : m'y suis-je bien pris, le blindage vous paraît-il suffisant et, accessoirement, puis-je supprimer le répertoire "home" qui s'est créé avec le compte, puisqu'il ne sert à rien ?
Oui. Après sans toutefois tomber dans la paranoïa, il faut savoir que les mots de passe de tes étudiants transiterons en clair sur le réseau, ce qui est un trou dans ton blindage (pour reprendre tes termes).
À mon avis, une solution de type scponly[1] sera beaucoup mieux.
[1] <http://www.sublimation.org/scponly/>
oui, et non, l'utilisation d'un FTP comme PureFTPD permet de maintenir une base d'utilisateur qui n'a rien a voir avec les utilisateurs du système, c'est parfois le meilleurs compromis entre facilité d'usage (pour le client) et sécurité (pour le serveur), dans la mesure ou les log/pass FTP ne peuvent jamais servir à autre chose qu'à du FTP (pas de ssh, pas d'appleshare, ... même si les accès sont ouverts).
Sinon, en simple aussi (coté client), il y'a WebDAV, qui utilise aussi une table d'utilisateur non-système, ça monte sur le bureau comme un disque partagé, et on écrit dessus en drag&drop. En plus c'est un protocole plus propre que le FTP, et c'est moins chiant pour les Firewall.
Dans les deux cas que je présente, tu as toutes latitudes pour régler finement les autorisations d'accès. Avec PureFTPD tu peux même restreindre l'accès en fonction de la plage horaire, limiter le débit, mettre des quotas sur les données échangées, ...
patpro
In article <358c0uF4k5pguU1@individual.net>, Matt <sbehzf@syrius.org>
wrote:
Questions : m'y suis-je bien pris, le blindage vous paraît-il suffisant
et, accessoirement, puis-je supprimer le répertoire "home" qui s'est
créé avec le compte, puisqu'il ne sert à rien ?
Oui.
Après sans toutefois tomber dans la paranoïa, il faut savoir que les mots
de passe de tes étudiants transiterons en clair sur le réseau, ce qui est
un trou dans ton blindage (pour reprendre tes termes).
À mon avis, une solution de type scponly[1] sera beaucoup mieux.
[1] <http://www.sublimation.org/scponly/>
oui, et non, l'utilisation d'un FTP comme PureFTPD permet de maintenir
une base d'utilisateur qui n'a rien a voir avec les utilisateurs du
système, c'est parfois le meilleurs compromis entre facilité d'usage
(pour le client) et sécurité (pour le serveur), dans la mesure ou les
log/pass FTP ne peuvent jamais servir à autre chose qu'à du FTP (pas de
ssh, pas d'appleshare, ... même si les accès sont ouverts).
Sinon, en simple aussi (coté client), il y'a WebDAV, qui utilise aussi
une table d'utilisateur non-système, ça monte sur le bureau comme un
disque partagé, et on écrit dessus en drag&drop. En plus c'est un
protocole plus propre que le FTP, et c'est moins chiant pour les
Firewall.
Dans les deux cas que je présente, tu as toutes latitudes pour régler
finement les autorisations d'accès. Avec PureFTPD tu peux même
restreindre l'accès en fonction de la plage horaire, limiter le débit,
mettre des quotas sur les données échangées, ...
Questions : m'y suis-je bien pris, le blindage vous paraît-il suffisant et, accessoirement, puis-je supprimer le répertoire "home" qui s'est créé avec le compte, puisqu'il ne sert à rien ?
Oui. Après sans toutefois tomber dans la paranoïa, il faut savoir que les mots de passe de tes étudiants transiterons en clair sur le réseau, ce qui est un trou dans ton blindage (pour reprendre tes termes).
À mon avis, une solution de type scponly[1] sera beaucoup mieux.
[1] <http://www.sublimation.org/scponly/>
oui, et non, l'utilisation d'un FTP comme PureFTPD permet de maintenir une base d'utilisateur qui n'a rien a voir avec les utilisateurs du système, c'est parfois le meilleurs compromis entre facilité d'usage (pour le client) et sécurité (pour le serveur), dans la mesure ou les log/pass FTP ne peuvent jamais servir à autre chose qu'à du FTP (pas de ssh, pas d'appleshare, ... même si les accès sont ouverts).
Sinon, en simple aussi (coté client), il y'a WebDAV, qui utilise aussi une table d'utilisateur non-système, ça monte sur le bureau comme un disque partagé, et on écrit dessus en drag&drop. En plus c'est un protocole plus propre que le FTP, et c'est moins chiant pour les Firewall.
Dans les deux cas que je présente, tu as toutes latitudes pour régler finement les autorisations d'accès. Avec PureFTPD tu peux même restreindre l'accès en fonction de la plage horaire, limiter le débit, mettre des quotas sur les données échangées, ...
patpro
patrick.noXmail.esnault
patpro ~ patrick proniewski wrote:
Sinon, en simple aussi (coté client), il y'a WebDAV, qui utilise aussi une table d'utilisateur non-système, ça monte sur le bureau comme un disque partagé, et on écrit dessus en drag&drop. En plus c'est un protocole plus propre que le FTP, et c'est moins chiant pour les Firewall.
J'aurais tendance à avoir une opinion inverse. Pensant faire simple j'avais installé un iDisk issue de .Mac qui utilise Webdav. - Mon Firewall Netasq avait une option cachée (en dehors des règles de filtrage) qui bloque spécifiquement ce protocole considéré comme douteux. Il m'a donc fallu un bon moment avant de le faire marcher. - Pour les mêmes raisons, des intervenants externes n'ont jamais réussi à utiliser mon iDisk et se faisaient jeter par les informaticiens de leur boîte pour cet "exotisme Apple". - Pour ceux qui réussissaient à se connecter la fiabilité était catastrophique ; mais c'est peut être un problème du iDisk.
J'ai maintenant un serveur FTP. L'avantage c'est que les responsables informatiques dans les boîtes acceptent d'aider les utilisateurs sur ce protocole. La fiabilité des transmissions est sans comparaison.
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Sinon, en simple aussi (coté client), il y'a WebDAV, qui utilise aussi
une table d'utilisateur non-système, ça monte sur le bureau comme un
disque partagé, et on écrit dessus en drag&drop. En plus c'est un
protocole plus propre que le FTP, et c'est moins chiant pour les
Firewall.
J'aurais tendance à avoir une opinion inverse.
Pensant faire simple j'avais installé un iDisk issue de .Mac qui utilise
Webdav.
- Mon Firewall Netasq avait une option cachée (en dehors des règles de
filtrage) qui bloque spécifiquement ce protocole considéré comme
douteux. Il m'a donc fallu un bon moment avant de le faire marcher.
- Pour les mêmes raisons, des intervenants externes n'ont jamais réussi
à utiliser mon iDisk et se faisaient jeter par les informaticiens de
leur boîte pour cet "exotisme Apple".
- Pour ceux qui réussissaient à se connecter la fiabilité était
catastrophique ; mais c'est peut être un problème du iDisk.
J'ai maintenant un serveur FTP. L'avantage c'est que les responsables
informatiques dans les boîtes acceptent d'aider les utilisateurs sur ce
protocole.
La fiabilité des transmissions est sans comparaison.
Sinon, en simple aussi (coté client), il y'a WebDAV, qui utilise aussi une table d'utilisateur non-système, ça monte sur le bureau comme un disque partagé, et on écrit dessus en drag&drop. En plus c'est un protocole plus propre que le FTP, et c'est moins chiant pour les Firewall.
J'aurais tendance à avoir une opinion inverse. Pensant faire simple j'avais installé un iDisk issue de .Mac qui utilise Webdav. - Mon Firewall Netasq avait une option cachée (en dehors des règles de filtrage) qui bloque spécifiquement ce protocole considéré comme douteux. Il m'a donc fallu un bon moment avant de le faire marcher. - Pour les mêmes raisons, des intervenants externes n'ont jamais réussi à utiliser mon iDisk et se faisaient jeter par les informaticiens de leur boîte pour cet "exotisme Apple". - Pour ceux qui réussissaient à se connecter la fiabilité était catastrophique ; mais c'est peut être un problème du iDisk.
J'ai maintenant un serveur FTP. L'avantage c'est que les responsables informatiques dans les boîtes acceptent d'aider les utilisateurs sur ce protocole. La fiabilité des transmissions est sans comparaison.
patpro ~ patrick proniewski
In article <1gqoljh.1oo4g5b2vabryN%, (Patrick ESNAULT) wrote:
patpro ~ patrick proniewski wrote:
Sinon, en simple aussi (coté client), il y'a WebDAV, qui utilise aussi une table d'utilisateur non-système, ça monte sur le bureau comme un disque partagé, et on écrit dessus en drag&drop. En plus c'est un protocole plus propre que le FTP, et c'est moins chiant pour les Firewall.
J'aurais tendance à avoir une opinion inverse. Pensant faire simple j'avais installé un iDisk issue de .Mac qui utilise Webdav. - Mon Firewall Netasq avait une option cachée (en dehors des règles de filtrage) qui bloque spécifiquement ce protocole considéré comme douteux. Il m'a donc fallu un bon moment avant de le faire marcher. - Pour les mêmes raisons, des intervenants externes n'ont jamais réussi à utiliser mon iDisk et se faisaient jeter par les informaticiens de leur boîte pour cet "exotisme Apple". - Pour ceux qui réussissaient à se connecter la fiabilité était catastrophique ; mais c'est peut être un problème du iDisk.
je comprends bien tes rétiscences, vu l'expérience que tu en as, mais pour n'avoir jamais utilisé WebDAV dans le contexte de l'iDisk, et l'avoir utilisé à partir de Apache+mod_dav, je peux te dire que ça marche très bien, et que contrairement au FTP il n'y a rien a expliquer. Pour les OS récents il n'y a meme pas besoin de client dédié, le Finder, ou l'explorateur windows ont ces fonctionnalités intégrées.
On peut l'utiliser sur HTTP (en clair) ou sur HTTPS (chiffré), ça passe par un port unique, le port 80, il n'y a pas d'histoire de mode actif ou passif, bref, c'est que du bonheur ;)
patpro
In article
<1gqoljh.1oo4g5b2vabryN%patrick.noXmail.esnault@cfd.noXmail.fr>,
patrick.noXmail.esnault@cfd.noXmail.fr (Patrick ESNAULT) wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Sinon, en simple aussi (coté client), il y'a WebDAV, qui utilise aussi
une table d'utilisateur non-système, ça monte sur le bureau comme un
disque partagé, et on écrit dessus en drag&drop. En plus c'est un
protocole plus propre que le FTP, et c'est moins chiant pour les
Firewall.
J'aurais tendance à avoir une opinion inverse.
Pensant faire simple j'avais installé un iDisk issue de .Mac qui utilise
Webdav.
- Mon Firewall Netasq avait une option cachée (en dehors des règles de
filtrage) qui bloque spécifiquement ce protocole considéré comme
douteux. Il m'a donc fallu un bon moment avant de le faire marcher.
- Pour les mêmes raisons, des intervenants externes n'ont jamais réussi
à utiliser mon iDisk et se faisaient jeter par les informaticiens de
leur boîte pour cet "exotisme Apple".
- Pour ceux qui réussissaient à se connecter la fiabilité était
catastrophique ; mais c'est peut être un problème du iDisk.
je comprends bien tes rétiscences, vu l'expérience que tu en as, mais
pour n'avoir jamais utilisé WebDAV dans le contexte de l'iDisk, et
l'avoir utilisé à partir de Apache+mod_dav, je peux te dire que ça
marche très bien, et que contrairement au FTP il n'y a rien a expliquer.
Pour les OS récents il n'y a meme pas besoin de client dédié, le Finder,
ou l'explorateur windows ont ces fonctionnalités intégrées.
On peut l'utiliser sur HTTP (en clair) ou sur HTTPS (chiffré), ça passe
par un port unique, le port 80, il n'y a pas d'histoire de mode actif ou
passif, bref, c'est que du bonheur ;)
In article <1gqoljh.1oo4g5b2vabryN%, (Patrick ESNAULT) wrote:
patpro ~ patrick proniewski wrote:
Sinon, en simple aussi (coté client), il y'a WebDAV, qui utilise aussi une table d'utilisateur non-système, ça monte sur le bureau comme un disque partagé, et on écrit dessus en drag&drop. En plus c'est un protocole plus propre que le FTP, et c'est moins chiant pour les Firewall.
J'aurais tendance à avoir une opinion inverse. Pensant faire simple j'avais installé un iDisk issue de .Mac qui utilise Webdav. - Mon Firewall Netasq avait une option cachée (en dehors des règles de filtrage) qui bloque spécifiquement ce protocole considéré comme douteux. Il m'a donc fallu un bon moment avant de le faire marcher. - Pour les mêmes raisons, des intervenants externes n'ont jamais réussi à utiliser mon iDisk et se faisaient jeter par les informaticiens de leur boîte pour cet "exotisme Apple". - Pour ceux qui réussissaient à se connecter la fiabilité était catastrophique ; mais c'est peut être un problème du iDisk.
je comprends bien tes rétiscences, vu l'expérience que tu en as, mais pour n'avoir jamais utilisé WebDAV dans le contexte de l'iDisk, et l'avoir utilisé à partir de Apache+mod_dav, je peux te dire que ça marche très bien, et que contrairement au FTP il n'y a rien a expliquer. Pour les OS récents il n'y a meme pas besoin de client dédié, le Finder, ou l'explorateur windows ont ces fonctionnalités intégrées.
On peut l'utiliser sur HTTP (en clair) ou sur HTTPS (chiffré), ça passe par un port unique, le port 80, il n'y a pas d'histoire de mode actif ou passif, bref, c'est que du bonheur ;)
patpro
patpro ~ patrick proniewski
In article , Matt wrote:
On Thu, 20 Jan 2005 09:19:09 +0100, patpro ~ patrick proniewski wrote:
oui, et non, l'utilisation d'un FTP comme PureFTPD permet de maintenir une base d'utilisateur qui n'a rien a voir avec les utilisateurs du système, c'est parfois le meilleurs compromis entre facilité d'usage (pour le client) et sécurité (pour le serveur), dans la mesure ou les log/pass FTP ne peuvent jamais servir à autre chose qu'à du FTP (pas de ssh, pas d'appleshare, ... même si les accès sont ouverts).
Oui je sais, je connais très bien pureftpd, mais j'ai préconisé scponly *si* le transit des mots de passe en clair gênerait Michel.
oui c'est une vrai alternative sécuritaire, mais ne pas avoir de compte système pour les utilisateurs finaux de service est aussi une politique interessante ;)
patpro
In article <359oi5F4i5q2cU1@individual.net>, Matt <sbehzf@syrius.org>
wrote:
On Thu, 20 Jan 2005 09:19:09 +0100,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
oui, et non, l'utilisation d'un FTP comme PureFTPD permet de maintenir
une base d'utilisateur qui n'a rien a voir avec les utilisateurs du
système, c'est parfois le meilleurs compromis entre facilité d'usage
(pour le client) et sécurité (pour le serveur), dans la mesure ou les
log/pass FTP ne peuvent jamais servir à autre chose qu'à du FTP (pas de
ssh, pas d'appleshare, ... même si les accès sont ouverts).
Oui je sais, je connais très bien pureftpd, mais j'ai préconisé scponly
*si* le transit des mots de passe en clair gênerait Michel.
oui c'est une vrai alternative sécuritaire, mais ne pas avoir de compte
système pour les utilisateurs finaux de service est aussi une politique
interessante ;)
On Thu, 20 Jan 2005 09:19:09 +0100, patpro ~ patrick proniewski wrote:
oui, et non, l'utilisation d'un FTP comme PureFTPD permet de maintenir une base d'utilisateur qui n'a rien a voir avec les utilisateurs du système, c'est parfois le meilleurs compromis entre facilité d'usage (pour le client) et sécurité (pour le serveur), dans la mesure ou les log/pass FTP ne peuvent jamais servir à autre chose qu'à du FTP (pas de ssh, pas d'appleshare, ... même si les accès sont ouverts).
Oui je sais, je connais très bien pureftpd, mais j'ai préconisé scponly *si* le transit des mots de passe en clair gênerait Michel.
oui c'est une vrai alternative sécuritaire, mais ne pas avoir de compte système pour les utilisateurs finaux de service est aussi une politique interessante ;)
patpro
Michel Henri
In article (Dans l'article) <1gqnynq.1xh90rqi6slmpN%, (Laurent Pertois) wrote (écrivait) :
Tu as modifié quoi dans le ftpd.conf ? Perso, quand je veux faire ce que tu décris, je fais un utilisateur, ensuite, je me donne des droits plus importants sur le dossier départ (cet utilisateur ne sera utilisé qu'en FTP), je le vide des dossiers par défaut de Mac OS X, je définis les autorisations d'accès et ça me suffit. Je modifie uniquement le /etc/ftpchroot en ajoutant le nom abrégé de cet utilisateur et il est bien cantonné à son dossier perso.
Oui, c'était juste pour leur définir un dossier d'accès particulier. Ça revient un peu au même.
-- Michel Henri (enlever les quatre lettres de fin d'alphabet pour me répondre)
In article (Dans l'article)
<1gqnynq.1xh90rqi6slmpN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote (écrivait) :
Tu as modifié quoi dans le ftpd.conf ? Perso, quand je veux faire ce que
tu décris, je fais un utilisateur, ensuite, je me donne des droits plus
importants sur le dossier départ (cet utilisateur ne sera utilisé qu'en
FTP), je le vide des dossiers par défaut de Mac OS X, je définis les
autorisations d'accès et ça me suffit. Je modifie uniquement le
/etc/ftpchroot en ajoutant le nom abrégé de cet utilisateur et il est
bien cantonné à son dossier perso.
Oui, c'était juste pour leur définir un dossier d'accès particulier. Ça
revient un peu au même.
--
Michel Henri (enlever les quatre lettres de fin d'alphabet pour me répondre)
In article (Dans l'article) <1gqnynq.1xh90rqi6slmpN%, (Laurent Pertois) wrote (écrivait) :
Tu as modifié quoi dans le ftpd.conf ? Perso, quand je veux faire ce que tu décris, je fais un utilisateur, ensuite, je me donne des droits plus importants sur le dossier départ (cet utilisateur ne sera utilisé qu'en FTP), je le vide des dossiers par défaut de Mac OS X, je définis les autorisations d'accès et ça me suffit. Je modifie uniquement le /etc/ftpchroot en ajoutant le nom abrégé de cet utilisateur et il est bien cantonné à son dossier perso.
Oui, c'était juste pour leur définir un dossier d'accès particulier. Ça revient un peu au même.
-- Michel Henri (enlever les quatre lettres de fin d'alphabet pour me répondre)
Michel Henri
In article (Dans l'article) , Matt wrote (écrivait) :
On Wed, 19 Jan 2005 23:43:16 +0100, Michel Henri wrote:
Bonjour,
Salut,
Premier point : je dois apparemment leur créer un compte utilisateur ordinaire. Exact ou peut-on créer des comptes "ftp seul" ?
Oui (en restreignant le shell de connexion des utilisateurs qui ne se connecteront que via FTP).
Comment fait-on ?
J'ai configuré les fichiers /etc/ftpchroot et /etc/ftpd.conf pour les mettre en mode "chroot" (c'est bien comme ça qu'on dit ?).
Oui plus ou moins.
Questions : m'y suis-je bien pris, le blindage vous paraît-il suffisant et, accessoirement, puis-je supprimer le répertoire "home" qui s'est créé avec le compte, puisqu'il ne sert à rien ?
Oui. Après sans toutefois tomber dans la paranoïa, il faut savoir que les mots de passe de tes étudiants transiterons en clair sur le réseau, ce qui est un trou dans ton blindage (pour reprendre tes termes).
Pas très grave. C'est pour ça que je veux que les possibilités de cet utilisateur (il n'y en a qu'un pour tout le monde, en fait) soient le plus limité possible. Pour l'instant, ils n'ont d'ailleurs aucun droit d'écriture.
-- Michel Henri (enlever les quatre lettres de fin d'alphabet pour me répondre)
In article (Dans l'article) <358c0uF4k5pguU1@individual.net>,
Matt <sbehzf@syrius.org> wrote (écrivait) :
On Wed, 19 Jan 2005 23:43:16 +0100,
Michel Henri <m_hewxynri@club-intzzzernet.fr.invalid> wrote:
Bonjour,
Salut,
Premier point : je dois apparemment leur créer un compte utilisateur
ordinaire. Exact ou peut-on créer des comptes "ftp seul" ?
Oui (en restreignant le shell de connexion des utilisateurs qui ne se
connecteront que via FTP).
Comment fait-on ?
J'ai configuré les fichiers /etc/ftpchroot et /etc/ftpd.conf pour les
mettre en mode "chroot" (c'est bien comme ça qu'on dit ?).
Oui plus ou moins.
Questions : m'y suis-je bien pris, le blindage vous paraît-il suffisant
et, accessoirement, puis-je supprimer le répertoire "home" qui s'est
créé avec le compte, puisqu'il ne sert à rien ?
Oui.
Après sans toutefois tomber dans la paranoïa, il faut savoir que les mots
de passe de tes étudiants transiterons en clair sur le réseau, ce qui est
un trou dans ton blindage (pour reprendre tes termes).
Pas très grave. C'est pour ça que je veux que les possibilités de cet
utilisateur (il n'y en a qu'un pour tout le monde, en fait) soient le
plus limité possible. Pour l'instant, ils n'ont d'ailleurs aucun droit
d'écriture.
--
Michel Henri (enlever les quatre lettres de fin d'alphabet pour me répondre)
In article (Dans l'article) , Matt wrote (écrivait) :
On Wed, 19 Jan 2005 23:43:16 +0100, Michel Henri wrote:
Bonjour,
Salut,
Premier point : je dois apparemment leur créer un compte utilisateur ordinaire. Exact ou peut-on créer des comptes "ftp seul" ?
Oui (en restreignant le shell de connexion des utilisateurs qui ne se connecteront que via FTP).
Comment fait-on ?
J'ai configuré les fichiers /etc/ftpchroot et /etc/ftpd.conf pour les mettre en mode "chroot" (c'est bien comme ça qu'on dit ?).
Oui plus ou moins.
Questions : m'y suis-je bien pris, le blindage vous paraît-il suffisant et, accessoirement, puis-je supprimer le répertoire "home" qui s'est créé avec le compte, puisqu'il ne sert à rien ?
Oui. Après sans toutefois tomber dans la paranoïa, il faut savoir que les mots de passe de tes étudiants transiterons en clair sur le réseau, ce qui est un trou dans ton blindage (pour reprendre tes termes).
Pas très grave. C'est pour ça que je veux que les possibilités de cet utilisateur (il n'y en a qu'un pour tout le monde, en fait) soient le plus limité possible. Pour l'instant, ils n'ont d'ailleurs aucun droit d'écriture.
-- Michel Henri (enlever les quatre lettres de fin d'alphabet pour me répondre)
Michel Henri
In article (Dans l'article) , Matt wrote (écrivait) :
Attribue-lui un shell restreint. Pour cela tu peux utiliser la manière décrite dans la man de ftpd, section "Setting up a restricted ftp subtree".
OK. Il n'y a pas d'accès anonyme, mais seulement un utilisateur "chroot" (plus les utilisateurs habituels du système, bien sûr). Dois-je absolument donner au dossier d'accès la structure compliquée décrite ? Le "ls" a l'air de fonctionner.
À propos de la sécurité, mon idée est qu'au pire, le mot de passe que j'ai donné à mes élèves soit piraté, et qu'on pourra aller consulter leurs travaux. Si le compte ne peut pas "sortir" du dossier dédié, ça ne peut pas faire plus de dégâts. Mais c'est peut-être une vision naïve des choses. Est-ce que le serveur ftp pourrait être détourné pour bidouiller mon système ?
-- Michel Henri (enlever les quatre lettres de fin d'alphabet pour me répondre)
In article (Dans l'article) <35aajaF4iog6bU3@individual.net>,
Matt <sbehzf@syrius.org> wrote (écrivait) :
Attribue-lui un shell restreint.
Pour cela tu peux utiliser la manière décrite dans la man de ftpd, section
"Setting up a restricted ftp subtree".
OK. Il n'y a pas d'accès anonyme, mais seulement un utilisateur "chroot"
(plus les utilisateurs habituels du système, bien sûr). Dois-je
absolument donner au dossier d'accès la structure compliquée décrite ?
Le "ls" a l'air de fonctionner.
À propos de la sécurité, mon idée est qu'au pire, le mot de passe que
j'ai donné à mes élèves soit piraté, et qu'on pourra aller consulter
leurs travaux. Si le compte ne peut pas "sortir" du dossier dédié, ça ne
peut pas faire plus de dégâts. Mais c'est peut-être une vision naïve des
choses. Est-ce que le serveur ftp pourrait être détourné pour bidouiller
mon système ?
--
Michel Henri (enlever les quatre lettres de fin d'alphabet pour me répondre)
In article (Dans l'article) , Matt wrote (écrivait) :
Attribue-lui un shell restreint. Pour cela tu peux utiliser la manière décrite dans la man de ftpd, section "Setting up a restricted ftp subtree".
OK. Il n'y a pas d'accès anonyme, mais seulement un utilisateur "chroot" (plus les utilisateurs habituels du système, bien sûr). Dois-je absolument donner au dossier d'accès la structure compliquée décrite ? Le "ls" a l'air de fonctionner.
À propos de la sécurité, mon idée est qu'au pire, le mot de passe que j'ai donné à mes élèves soit piraté, et qu'on pourra aller consulter leurs travaux. Si le compte ne peut pas "sortir" du dossier dédié, ça ne peut pas faire plus de dégâts. Mais c'est peut-être une vision naïve des choses. Est-ce que le serveur ftp pourrait être détourné pour bidouiller mon système ?
-- Michel Henri (enlever les quatre lettres de fin d'alphabet pour me répondre)
Michel Henri
In article (Dans l'article) , Matt wrote (écrivait) :
La structure impliquant d'avoir les exécutables dans la cellule chroot minimalise les risques.
Quel genre de risques ?
-- Michel Henri (enlever les quatre lettres de fin d'alphabet pour me répondre)
In article (Dans l'article) <35atd6F4i1pj3U1@individual.net>,
Matt <sbehzf@syrius.org> wrote (écrivait) :
La structure impliquant d'avoir les exécutables dans la cellule chroot
minimalise les risques.
Quel genre de risques ?
--
Michel Henri (enlever les quatre lettres de fin d'alphabet pour me répondre)
