Ben si tu as une méthode dont tu es content, pourquoi voudrais-tu en changer ?
Nous, on estime que la présente méthode est “parfaite”. L’utilisateur ne peux naviguer que dans un univers TRÈS restreint.
[quote=“ricardo”]Ben si tu as une méthode dont tu es content, pourquoi voudrais-tu en changer ?
Nous, on estime que la présente méthode est “parfaite”. L’utilisateur ne peux naviguer que dans un univers TRÈS restreint.[/quote]
bien oui je c’est bien sa , mais comme les 2 méthodes semble proposée les mêmes avantages, c’est a dir bloquer les users dans leur homes et les limiter au sftp .
l’une avec des paquet supplémentaire a openssh et l’autre non, y’a forcement une différence qui justifie l’ajout de paquet mais je ne la voie pas (je suis pas un expaire 
) . Aussi j’aimerai apprendre , les pours , et les contres, ensuite chacun choisi en fonction de c’est priorités et/ou directives (ex facilité de mise en œuvre , sécurités accru , flexibilité … ).
Bon j’ai quant même trouver quelque différences : avec rssh on a un réglage plus fin des droits, mais c’est un peut plus compliquer a maître en œuvre. niveaux sécurité sa ce vaux on dirais .
Salut
Non, la méthode sftp+rssh ne bloque pas les users dans leur home: avec cette méthode, tu crées un chroot dans lequel apparaissent les dossiers dev etc et lib puis tous les dossiers que tu as besion de rajouter (des homes pour tes users si tu le désires). Les users ne peuvent sortir de ce chroot (qui n’est pas leur home).
Donc la remarque du lien que tu cites [quote]Utiliser rssh comme shell alternatif, c’est un shell qui limite l’utilisateur à du SFTP, SCP, CVS, RSYNC etc. On choisit ce qu’on veut tolérer. Mais, l’utilisateur peut quand même se promener dans le système (tout « / »).[/quote] est fausse car imprécise: par “tout « / »”, il faut comprendre le / du chroot. Ton serveur ne se limite pas du tout à ça (le / du serveur n’est bien évidemment pas le / du chroot).
De plus avec une gestion fine des droits, les users ne peuvent pas trop se ballader dans les dossiers sensibles du chroot: tu peux interdire à tes users en lecture et écriture les etc lib et usr du chroot, et interdire en écriture dev. Puis mettre les permissions que tu veux sur les dossiers que tu auras rajouté.
Maintenant, la méthode proposé par ton lien (et donc par openssh) doit aussi être efficace. Mais, si tes users sont enfermés dans leurs homes respectifs, ça empêche de partager un dossier commun (travail collaboratif par exemple ) entre différents users. Ça peut en gêner certains.
Avec sftp+rssh, les users peuvent se ballader dans la racine du chroot mais ne peuvent rien y faire (ils ne peuvent pas voir le contenu de etc, lib et usr, et même s’ils peuvent voir le contenu de dev, ils ne peuvent rien y faire). Donc au bilan leur ballade dans le chroot se résume à pas gd chose…Et ils ne peuvent bien évidemment pas se ballader en dehors du chroot (sur ton serveur).
@ hulk :
Crois-bien que s’il en avait été autrement, je n’aurais pas donné de permission à ce voyou de Yanlolot pour aller sur mon serveur 
Merci beaucoup a tous pour ces infos, tous et plus claire pour moi! 
Salut tout le monde,
J’ai suivi le tuto proposé dans le premier post, très détaillé et facile par ailleurs, seulement j’ai un soucis au niveau du chroot.
Si j’ai bien compris, une fois chroot bien configuré l’utilisateur ne peut pas pouvoir remonter jusqu’à la racine du système et ainsi voir les etc, usr, var et autres ?
Parce que dans mon cas l’utilisateurs peut se balader où il veut.
Au besoin, mon fichier rssh.conf :
logfacility = LOG_USER
allowsftp
umask=022
chrootpath = “/home/sftp”
Petite question, mon utilisateur, appelont-le “machin”, doit avoir comme chroot /home/machin obligatoirement ?
si je me log en tant que : machin@localhost, je vois toute l’arborescence de mon serveur : fichiers et autres. Cependant je ne peux pas faire “cat /etc/rssh.conf”, est-ce une sécurité suffisante de simplement ne pas pouvoir exécuter les commandes habituelles ?
Merci de vos réponses,
Seb
Ben si tu suis ça à la lettre, ‘machin’ ne pourra pas remonter plus haut que /home/sftp, qu’il ne verra même pas, seulement :
sftp >
comme invite, si ma mémoire est bonne.
[quote]III Création du chroot
Nous allons “chrooter” nos futurs utilisateurs du serveur sftp dans un dossier, nous nous servirons dans notre cas de /home/sftp:
Code:
#mkdir /home/sftp
L’intérêt est que ces utilisateurs verront /home/sftp comme racine, et ne pourront agir que dans celui-là (et uniquement avec les commandes fournies par sftp, étant donné qu’on leur donnera comme shell rssh).[/quote]
Complètement d’accord, quand il se connecte, le prompt est “sftp>”, mais un coup de “lcd …” et il remonte sans problème chez moi. Après s’il ne peut pas effectuer de commande donc ça me va à peu près, mais je pense que j’ai du mal faire un truc.
Je ne comprends pas ta commande "lcd…"
Peux-tu me la donner en entier car moi, j’ai essayé par tous les moyens et je n’ai jamais réussi à remonter plus haut.
C’est complètement de ma faute, je me suis rendu compte en testant avec l’ami pour lequel j’ai fait ce compte qu’en fait, voila ce qui ce passait :
_ Je me connectais en ssh sur mon serveur
_ Je me loggais avec sftp machin@localhost via mon ssh
_ login/mdp correct -> connection acceptée
_ et en faisant “lcd …” je remontais dans l’arborescence de mon système local.
Je sais que ça n’a pas l’air très clair, mais dans ma tête ça l’est ^^
Merci de ton aide en tout cas 
bonjour
j’ai suivi le tuto et j’ai cela comme erreur
[R] Connexion à ip -> IP=ip PORT=6558
[R] Connecté à ip
[R] Algorithme de clé hôte ssh-RSA, taille 2048 bits.
[R] Empreinte (MD5): a7:6b:12:a4:e7:b2:1e:a6:7b:da:4b:ae:22:0e:cd:fe
[R] Échange de clés : le cryptage de session diffie-hellman-group14-sha1.: aes256-ctr, MAC: hmac-sha1, compression : zlib@openssh.com.
[R] Auth Type: Password
[R] L'authentification a réussi
[R] SSH Connexion ouverte
[R] Échec de la connexion (SFTP sub-system request timed out)
[R] Mise en Attente de 120 secondes avant la tentative de reconnexion N°1
pouvez vous m’aider stp merci d’avance
P.S mon utilisateur qui a pas été créer avec le tuto sa fonctionne et je peut reculer dans les dossier … comprend pas
Bonjour à tous,
J’ai un petit problème de « chrootage ».
En effet, j’ai créé mon chroot dans /media/raid/sftp et j’ai bien modifier le ficher /etc/rssh.conf en y ajoutant la ligne chrootpath = /media/raid/sftp.
Pourtant lorsque je crée un nouvel utilisateur, son dossier home se retrouve dans le /home et non dans le /media/raid/sftp.
Quelqu’un voit d’ou peux venir le problème?
Bonjour,
Merci pour ce post très utile, qui correspond pile poil à mes besoins !
J’ai juste apporté deux modifications :
1Pour ouvrir un peu plus la machine au scp :
J’ai juste rajouté l’option : allowscp à rssh.conf
et j’ai fait un ./copie_binaire /usr/bin/scp /home/sftp
pour que le chroot serve aussi au scp
2 Pour que l’utilisateur machin se retrouve loggué directement dans un répertoire où il a le droit d’écrire :
j’ai changé le home repertoire de machin à /home/sftp/home/machin dans le /etc/passwd de la machine (pas dans le chroot)
Encore merci pour ce post!
Bonjour,
Super tuto pour sécuriser un FTP.
Néanmoins, j’ai un gros petit souci quand je le suis.
Tout se passe bien, j’ai bien mon sftp qui fonctionne avec un compte machin qui accède bien au dossier. Mais le problème c’est qu’après avoir suivi tout ce tuto, je n’arrive plus à me connecter à mon serveur via Putty (que ce soit en compte classique ou root) lors de mes prochaines connexions, il me marque access denied. En testant avec le compte machin, je n’ai pas de réponse mais mon Putty se ferme.
J’ai donc réinstallé mon serveur pour avoir à nouveau mon accès, j’ai refais tout ce tuto en ne mettant pas la ligne “PermitRootLogin no” (car je pensais que ça venait de ça). Mais j’ai toujours le même résultat.
Une idée ?
Tout en sachant que via le compte machin, mon sftp fonctionne.
Merci d’avance.
Y accèdes-tu via ssh ?
Si non, vérifie la ligne Allowuser dans /etc/ssh/sshd_config :
si elle ne contient que machin, c’est normal que tu ne puisses plus te connecter via ssh. Il faut que tu y rajoutes le login avec lequel tu veux te connecter à ton serveur.
Oui effectivement, c’est logique.
Maintenant tout marche.
Merci beaucoup.
[quote=“lol”]Salut,
J’ai suivi le tuto, c’est cool, ça fonctionne très bien. Merci
Au passage j’ai corrigé 2/3 petits trucs sur le Wiki.
Je voulais poser une question au sujet des clefs… Cela n’a pas été abordé.
Il faut créer une clef (sans passphrase) chez le client, et copier la clef dans “.ssh/authorized_keys” sur le serveur.
Avec le chroot, comment cela doit fonctionner ?
Faut-il avoir .ssh/authorized_keys dans /home/machin ou /home/sftp ?
Je vais essayer… 
[/quote]
Laurent, peux-tu m’expliquer exactement ce que je dois faire car je pédale dans la semoule avec cette histoire de clefs.
Je prends ton exemple comme client pour te connecter sur mon serveur.
Avant, j’avais la reconnaissance par MDP — j’ai modifié avec reconnaissance par clefs.
Pour ricardo, no problem j’ai bien la connexion mais pour le client en sftp ‘Lol’, comment dois-je pratiquer ?
Sur mon serveur, ton /home est réduit à 3 fichiers : .bash_logout ; .bashrc ; .profile
PAS de ‘.ssh’ ni a fortiori de .ssh/authorized_keys.
Faut-il que je crée ces dossier/fichier ?
Avec quoi dois-je remplir le 'authorized_keys ?
Est-ce que je dois recréer un second jeu de clefs ?
Merci d’être précis dans ton explication.
Salut,
En principe:
- Je crée un jeux de clef sur ma machine;
- Je t’envoie la clef (soit avec la commande ssh-copy-id - mais ce n’est plus possible car tu as désactivé l’accès par mdp - soit en pièce jointe par mail ou par n’importe quel autre moyen)
- Tu copie ma clef publique dans mon /home/lol/.ssh
- Je me connecte avec la clef (ssh ricardo - en ayant précisé dans mon ~/.ssh/config les paramètres)
[quote=“lol”]Salut,
En principe:
- Je crée un jeux de clef sur ma machine;
- Je t’envoie la clef (soit avec la commande ssh-copy-id - mais ce n’est plus possible car tu as désactivé l’accès par mdp - soit en pièce jointe par mail ou par n’importe quel autre moyen)
- Tu copie ma clef publique dans mon /home/lol/.ssh
- Je me connecte avec la clef (ssh ricardo - en ayant précisé dans mon ~/.ssh/config les paramètres)
[/quote]
Oui, on va faire comme ça pour tester mais ce n’est quand même pas pratique.
Il va falloir que Yann nous trouve un moyen plus “général”, qui puisse s’adapter à tous les “ayant-droits”, si c’est possible.
Je pensais que la création se serait faite du côté du serveur pour la clef publique et que le client ait une demande d’acceptation qui lui créerait SA clef privée ?
EDIT :
Je me rends compte de ma réponse conne 
Ainsi, tout le monde pourrait se connecter 
Re,
Tu peux utiliser la même clef pour tout le monde.
Il suffit de l’envoyer aux “clients” et demander qu’ils la place au bon endroit.
S’ils sont sous Windows il faudra la convertir (avec puttygen) par exemple.