Si tu as un OpenSSH assez récent (il me semble que ça marche depuis le 4.8 ou le 4.9, de mémoire), pourquoi ne pas utiliser le sFTP intégré à OpenSSH ?
Il permet notamment d'interdire le login à un shell, pour certains utilisateurs, par exemple membres d'un groupe, et de ne leur laisser que la possibilité de se connecter pour faire des opérations en sFTP.
Dans le fichier de config (sous Debian, par exemple) "/etc/ssh/sshd_config", tu remplaces :
Subsystem sftp /usr/lib/openssh/sftp-server
par :
Subsystem sftp internal-sftp
Pour matcher qui est restreint au chrooted sFTP, et à la vue de quoi il se limite, par exemple en limitant l'accès pour les utilisateurs membres du groupe "sftponly" à leur "/home/$user", tu rajoutes aussi :
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Et hop : ça marche nickel - les utilisateurs membres de ce groupe n'auront accès à rien d'autre que ce qui est dans leur "/home/$user".
Ça évite notamment de se trimballer un chroot complet (avec des binaires et la totale, ce qui est très douteux, si le but est d'améliorer la sécurité), qu'il faudra créer, maintenir, et ce pour autant d'utilisateurs qu'il y en a... : dans le chrooted sFTP d'OpenSSH, seules les données sont accessibles (ça n'a rien à voir avec le chroot traditionnel, qui est une méthode très inefficace pour améliorer la sécurité, puisqu'il se contente généralement de recopier les mêmes binaires que ceux de la racine de l'arborescence ; mêmes binaires soumis aux même failles, en outre) - c'est plus à voir comme des ACL propres pour savoir qui peut accéder à un shell, et qui ne peut faire que des bêtes scp et cie...
# Le sFTP intégré à OpenSSH ?
Posté par Aefron . En réponse au message sftp sur redhat el5. Évalué à 4.
Il permet notamment d'interdire le login à un shell, pour certains utilisateurs, par exemple membres d'un groupe, et de ne leur laisser que la possibilité de se connecter pour faire des opérations en sFTP.
Dans le fichier de config (sous Debian, par exemple) "/etc/ssh/sshd_config", tu remplaces :
Subsystem sftp /usr/lib/openssh/sftp-server
par :
Subsystem sftp internal-sftp
Pour matcher qui est restreint au chrooted sFTP, et à la vue de quoi il se limite, par exemple en limitant l'accès pour les utilisateurs membres du groupe "sftponly" à leur "/home/$user", tu rajoutes aussi :
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Et hop : ça marche nickel - les utilisateurs membres de ce groupe n'auront accès à rien d'autre que ce qui est dans leur "/home/$user".
Un tuto pus détaillé ici, par exemple : http://www.debian-administration.org/articles/590
Ça évite notamment de se trimballer un chroot complet (avec des binaires et la totale, ce qui est très douteux, si le but est d'améliorer la sécurité), qu'il faudra créer, maintenir, et ce pour autant d'utilisateurs qu'il y en a... : dans le chrooted sFTP d'OpenSSH, seules les données sont accessibles (ça n'a rien à voir avec le chroot traditionnel, qui est une méthode très inefficace pour améliorer la sécurité, puisqu'il se contente généralement de recopier les mêmes binaires que ceux de la racine de l'arborescence ; mêmes binaires soumis aux même failles, en outre) - c'est plus à voir comme des ACL propres pour savoir qui peut accéder à un shell, et qui ne peut faire que des bêtes scp et cie...