Je sais que cette question a déjà été discutée, mais en lisant les articles, je n'ai pas pu trouver les réponses, car certains ont dit "oui, umask peut fonctionner", et d'autres ont dit "La commande de mise OpenSSH conserve toujours les autorisations"
Avant tout juste pour préciser:
- J'utilise OpenSSH 5.9 sur RHEL 6.2
- J'ai configuré un serveur SFTP chrooté, en utilisant le
internal-sftp
sous-système, avec-u 0002
pour umask - Je précise que je n'utilise pas l' option
-p
ou-P
D'après ce que j'ai lu d'une part: il existe de nombreuses façons de définir umask pour les transferts SFTP:
- possibilité
-u
deinternal-sftp
(ousftp-server
), depuis OpenSSH 5.4 - créer un wrapper pour
sftp-server
(dans lequel nous définissons explicitement le umask - cela ne convient pas à l'environnement chrooté btw) - ajouter une configuration spécifique dans le
pam.d/sshd
fichier
Par contre j'ai lu:
Le client et le serveur OpenSSH SFTP transfèrent les autorisations (en tant qu'extension) et créent le fichier distant avec les autorisations du côté local. AFAICT, il n'y a aucun moyen de désactiver ce comportement.
J'ai donc fait le test suivant:
Sur mon client, j'ai créé un fichier MYFILE
et un répertoire MYDIR
avec les autorisations 600 et 700.
Puis avec des sftp
commandes:
mkdir => the new directory has permissions following the umask (OK)
put MYFILE => MYFILE has same permissions as on client (KO)
put -r MYDIR => MYDIR has same permissions as on client (KO)
Si je modifie les autorisations de MYFILE
et MYDIR
côté client et que je les télécharge à nouveau, j'obtiens les nouvelles autorisations côté serveur.
J'ai également essayé la pam.d
solution, mais cela n'a rien changé.
Alors maintenant, je suis confus:
D'après ce que j'ai testé et une partie de ce que j'ai lu, je dirais qu'OpenSSH conserve toujours les autorisations. Mais comme de nombreux articles disent qu'un umask pourrait être défini, je peux imaginer que je fais une mauvaise chose dans mes configurations de test.
J'apprécierais quelques commentaires expérimentés.
Je vous remercie.