Chroot rssh

Bonjour,
Alors j’ai suivi l’excellent tutoriel suivant : isalo.org/wiki.debian-fr/ind … _du_chroot

J’aurais cependant besoin d’aide. En effet, lors de la connexion d’un utilisateur, il voit les dossiers /dev /etc/ /lib et /usr . J’aurais aimé que l’utilisateur arrive dans un environnement qui lui semble vide.

Comment puis-je faire?

serveur-sftp-shell-reduit-rssh-et-chroot-t27796.html
Ce que verra l’utilisateur, c’est ça :
sftp>
et s’il ‘ls’, il verra ça :
.bash_logout
.bashrc
.profile

Pas plus.

EDIT :
pourtant, c’est le même tuto qui a été repris dans le wiki :017

Le tuto du wiki n’est pas une copie du fil que tu proposes?

En tout cas, j’ai droit de les voir moi :

sftp> ls dev etc lib usr

J’ai repris le wiki à zero, en y apportant une petite modification.
Le chroot n’est pas installé dans /home/sftp, mais dans /home.
Ainsi, chaque utilisateur est automatiquement placé dans /home/utilisateur.

Ils peuvent avoir accès à /home par contre, et visiter les dossiers des autres utilisateurs… Donc c’est raté pour le chroot confidentiel avec cette méthode aussi…

Dans tous les cas c’est limite, car si n’importe qui a accès à etc/passwd, ça devient coton…

Suffit de mettre les droits appropriés sur chaque dossier utilisateur (chmod -R o-rwxs /home/utilisateur et umask 00?7), seul le propriétaire et le groupe pourront alors y accéder.

Normalement les mots de passe ne sont pas stockés dans /etc/passwd mais dans /etc/shadow que seul root peut lire.

Tu peux aussi simplement changer le répertoire d’arriver de l’utilisateur, moi ça marche comme ça.
Dans mon /etc/passwd:
share:x:1001:1002:,:/home/share/FichiersEnPartage/:/usr/bin/rssh

Le /home/share/etc/passwd par contre j’ai pas bien compris comment ça marchait, mais le répertoire d’arrivé ne dépend pas de lui apparemment.

[quote=“syam”]
Normalement les mots de passe ne sont pas stockés dans /etc/passwd mais dans /etc/shadow que seul root peut lire.[/quote]
C’est déja ça alors :slightly_smiling: .
Le répertoire d’arrivée importe peu si n’importe qui peut remonter ensuite dans l’arborescence. (mais merci ça pourra servir).

@syam : le chmod et le umask, ce sont les commandes à lancer en tant que root? Parce que si je le fais sur le répertoire etc, impossible de se connecter ensuite…

Mes etc/ usr/ lib/ et dev/ ont tous root comme proprio et ça marche bien. Ça parait logique, regarde tes fichiers originaux quand sftp va chercher ses librairies, elles sont bien root. Et pourtant tu te connectes bien en sftp sur un autre utilisateur que root…
Pour te rassurer mon dossier /home/share:

[code].:
total 44
drwxr-xr-x 7 share share 4096 janv. 23 14:45 .
drwxr-xr-x 4 root root 4096 janv. 21 16:35 …
-rw------- 1 root root 641 janv. 21 22:00 .bash_history
-rw-r–r-- 1 root root 220 janv. 21 16:35 .bash_logout
-rw-r–r-- 1 root root 3409 janv. 21 17:05 .bashrc
drwxr-xr-x 2 root root 4096 janv. 23 13:49 dev
drwxr-xr-x 2 root root 4096 janv. 21 23:34 etc
drwxr-xr-x 3 root root 4096 janv. 23 14:25 FichiersEnPartage
drwxr-xr-x 3 root root 4096 janv. 23 14:21 lib
-rw-r–r-- 1 root root 675 janv. 21 16:35 .profile
drwxr-xr-x 4 root root 4096 janv. 22 15:40 usr

./dev:
total 8
drwxr-xr-x 2 root root 4096 janv. 23 13:49 .
drwxr-xr-x 7 share share 4096 janv. 23 14:45 …
srw-rw-rw- 1 root root 0 janv. 23 13:49 log
crw-rw-rw- 1 root root 1, 3 janv. 21 23:27 null

./etc:
total 12
drwxr-xr-x 2 root root 4096 janv. 21 23:34 .
drwxr-xr-x 7 share share 4096 janv. 23 14:45 …
-rw-r–r-- 1 root root 67 janv. 23 15:42 passwd

./FichiersEnPartage:
total 57240
drwxr-xr-x 3 root root 4096 janv. 23 14:25 .
drwxr-xr-x 7 share share 4096 janv. 23 14:45 …
-rw-r–r-- 1 share share 9741413 janv. 22 17:01 _2_bad Trap VIP.mp3
-rw-r–r-- 1 share share 3301659 janv. 22 17:02 64 bar.mp3
-rw-r–r-- 1 share share 5998747 janv. 22 17:03 About The Bass.mp3
-rw-r–r-- 1 share share 3845209 janv. 22 17:03 Adrenaline.mp3
-rw-r–r-- 1 share share 7166748 janv. 22 17:04 Alive (Pegboard Nerds Remix).mp3
-rw-r–r-- 1 share share 6210694 janv. 22 17:06 Another Day (Ft. Popeska) (xKore Remix).mp3
-rw-r–r-- 1 share share 5107514 janv. 22 17:06 Anton Serra Freesthaï 2.mp3

… etc …
[/code]

Pour le chmod oui tu es obligé de le lancer en tant que root vu qu’on ne peux pas ce connecter en ssh sur notre utilisateur chrooté.
Tu fais un petit

Ne le fait peut être pas sur ton répertoire de partage.

Toute fois, une question, pourquoi veut tu protéger ces répertoires, tes commandes sont limités sur ton sftp, non ?
Moi j’ai ça:

sftp> delete Blow\ My\ Mind.mp3 Invalid command.

Dans tous les cas du moment que ton utilisateur peut juste lire tes fichiers et traverser les dossiers. Je ne vois pas où est la faille ?

EDIT:

sftp> rm Blow\ My\ Mind.mp3 Removing /FichiersEnPartage/Blow My Mind.mp3 Couldn't delete file: Permission denied

J’ai dit une bêtise (encore), tu peux te connecter à ton utilisateur chrooté en passant pas un autre utilisateur qui à l’accès ssh, en précisant que tu veux utiliser bash au lieu de rssh comme shell:

Si je veux cacher ces dossiers, c’est pour éviter de perdre les éventuels utilisateurs. Si déja ils s’en sortent avec filezilla, ce sera une belle victoire.

Et puis s’ils peuvent lire ces fichiers, j’ai comme l’impression que ça ne va pas du point de vue sécurité. (je suis parano?)

En tout cas, si user1 peut lire les fichiers de user2, alors que user2 voulait les garder invisibles, ce n’est pas correct.

Autre problème, si l’utilisateur fait un>get fichier
Alors le fichier est enregistré à la racine du chroot…

Merci pour vos réponses, je vais pouvoir bricoler quelque chose de convenable. :smiley:

Du coup, j’ai mis dans les /etc/rssh.conf un umask à OO6 seulement. Il faut que j’arrive à restreindre l’accès aux dossier à seulement un utilisateur. man chown, à nous deux!

edit : chmod -R 600 fait bien l’affaire?

Ben non, ça ne va pas, le propriétaire du dossier ne peux plus s’y déplacer…

siteduzero.com/informatique/ … -d-acces-1

Je tablerais sur un 500 si j’ai bien compris, mais le proprio ne pourra pas modifier ses propres fichiers, donc 700 sinon.

EDIT: enfin vu que c’est juste pour pouvoir traverser tes dossiers: chmod u+x Dossier

Pourquoi u+x? Je ne veux pas rendre les fichiers éxécutables, mais seulement lisibles et inscriptibles par l’user.

x c’est exécutable pour les fichiers et “traversable” pour les dossiers

Tu as raison, il faut le +x pour se déplacer dans un répertoire! :slightly_smiling:

Donc la bonne commande, c’était : chmod 700 dossier