Liens connexes

Dépêche modérée par

Dépêche éditée par

: Un pas de plus vers la démocratisation du sftp

Posté par TeXitoi (Jabber id, page perso, ). Modéré le 22 février 2008.
1
Une nouvelle fonctionnalité se rajoute à OpenSSH : ChrootDirectory. Ainsi, il est facile de chrooter suite à la connexion d'un utilisateur. Cela permet de limiter la vision du système de fichier à un sous-ensemble lorsque cet utilisateur se connecte en ssh.

Combiné au serveur sftp intégré à sshd, il est possible de limiter l'utilisateur à une partie du système de fichier ne possédant aucun binaire, aucune bibliothèque, ni aucun node, comme ça aurait du être le cas si le server sftp n'était pas intégré à sshd. Par exemple, les hébergeurs web pourront maintenant, grâce à cette fonctionnalité, remplacer ftp par sftp.

> Lire la suite (51 commentaires, moyenne: 2,9).   [dépêche : 1127 caractères]

Pour rendre l'accès limité au sftp pour l'utilisateur michu, en supposant que son repertoire de pages web est dans /var/www/users/michu, rajoutez ça à votre /etc/ssh/sshd_config (avec la version CVS d'OpenSSH) :
Match group webuser
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
ChrootDirectory /var/www/users


Il peut également être nécessaire de changer le système sftp par celui inclu dans sshd :
#Subsystem sftp /usr/libexec/sftp-server
Subsystem sftp internal-sftp


Mettez madame michu dans le groupe webuser en groupe principal, et mettez-lui comme home /michu. Faites bien attention aux droits du répertoire /var/www/users/ pour qu'elle n'ait accès qu'à /var/www/users/michu et rien d'autre. Vous pouvez alors mettre ftp à la poubelle.

Petit inconvénient : Madame Michu ne pourra pas utiliser scp, elle sera limité à sftp.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Remplacer ? Pas tout à fait

Posté par Arnaud (page perso, ) le 22/02/2008 à 17:26. (lien). Évalué à 3.

Il y a de fortes chances que les hébergeurs Web gardent quand même le FTP, qui reste (hélas ?) le plus grand dénominateur commun.

Mais pour les geeks en herbe qui administrent leurs machines et pour les entreprises, c'est une excellente nouvelle. Plus de daemon FTP = un process de moins = moins d'administration et de failles potentielles. Surtout que ça pullulait à une certaine époque, les problèmes de sécurité avec les serveurs FTP...

C'est déja possible avec scponly

Posté par Aurelien () le 22/02/2008 à 17:55. (lien). Évalué à 4.

Il y a une "extention" qui est en fait un shell, elle permet de forcer les utilisateurs à ne faire que du scp ou du sftp, mais aussi de créer des chroot (avec juste ce qu'il faut de binaire pour que scponly fonctionne).
Voir http://sublimation.org/scponly/wiki/index.php/Main_Page pour plus d'information.
Je l'utilise pas mal car j'aime pas donner des shells a qui doit juste deposer/effacer/... des fichiers dans les répertoire applicatifs des serveurs.

Tant mieux si cette fonctionnalité est directement intégrée a OpenSSH, ce sera plus propre.

excellente nouvelle

Posté par William Dauchy (page perso, ) le 22/02/2008 à 19:23. (lien). Évalué à 3.

C'est juste une excellente nouvelle :-)

--
Chty

Je commence à être perdu...

Posté par Zenitram (page perso, ) le 22/02/2008 à 20:49. (lien). Évalué à 1.

SFTP (SSH FTP)
SFTP (Secure FTP)
FTPS (FTP over SSL)
Je commence à être perdu moi!

Quel est l'avantage de SFTP par rapport à FTPS?
Pour moi, un FTP sécurisé existait déjà, et ce n'est pas cette modification qui va changer la non-volonté des gens à passer à du secure, pourquoi cet optimisme?

Et ca commence à me faire bizarre de tout faire passer par SSH...
Pour moi, une appli une fonction SSH pour l'accès, et FTP(S) pour les transferts...

Et si je comprend bien la présentation (n'hésitez pas à me corriger!), si je configure pour avoir du SFTP chrooté pour mes "clients", je ne pourrai plus faire de scp? Ou tout le monde n'est pas logé à la même enseigne et on peut chrooter à la tête du login?

PS : sinon, une première page pour un commit CVS, ca fait pas un peu beaucoup?

Plus précisément

Posté par Nicolas (page perso, ) le 22/02/2008 à 22:35. (lien). Évalué à 3.

Serait-il possible d'attribuer un répertoire d'accueil pour chaque user ?
Je veux dire que là, michu est chrooté dans /var/www/users, et donc il "voit" les autres répertoires, et doit rentrer dans le sien. Même si les droits sont mis en place pour qu'il ne puisse pas rentrer dans les autres répertoires, il les voit.

Y a t-il une possibilité de chroot unique pour un user, ou alors est-ce une feature qui sera fait dans l'avenir/jamais ?

Utilité de FTP ?

Posté par MilkaJinka () le 23/02/2008 à 11:12. (lien). Évalué à 5.

Je me demande à quoi peut bien encore servir FTP aujourd'hui, alors que le protocole est tellement mal fichu qu'il était déjà quasiment obsolète lors de sa conception... Pourquoi continuer de se le coltiner ?

La seule raison que je connaisse, c'est que comme il y a moins de bande passante réservée aux contrôles, le taux de téléchargement peut être un peu supérieur (au prix d'un risque d'erreurs plus élevé).

On peut très bien télécharger via HTTP, gérer ses données aussi avec les extensions WebDav, on a SSH et SFTP, on a Bittorrent... Que reste-t-il au vilain petit canard ?

--
Persiste.

Utilisable depuis longtemps grace à un patch

Posté par Olivier (page perso, ) le 23/02/2008 à 18:33. (lien). Évalué à 1.

Avec le patch http://chrootssh.sourceforge.net/index.php , il est faisable depuis longtemps d'enfermer un utilisateur SSH ou SFTP dans un chroot.

Le patch ne fait que quelques lignes, et il il suffisait de déclarer le chroot dans le /etc/passwd :

ftpuser:1010:1010:FTP anonymous account,,,:/var/chroot/ftpuser/./:/bin/sh

C'est le "./" à la fin du paramètre "HOME" du /etc/passwd qui déclenche l'utilisation du chroot par SSH.

J'ai utilisé cette technique pendant longtemps sur mes serveurs SSH/SFTP, avant de passer en FTPS (ProFTPD+TLS)

Revenir en haut de page