Fichiers SSHFS d'un serveur à un autre
J'essaie de trouver le moyen le plus sûr de transférer des fichiers d'un serveur à un autre.
J'ai l'architecture suivante:
Actuellement, j'utilise l'utilisateur principal salamis pour monter les répertoires.
Les fichiers du répertoire d'origine sont créés via un gestionnaire de fichiers PHP elfinder.
Malheureusement, je ne suis pas en mesure de move, rename ou delete aucun fichier du répertoire monté via PHP. Je reçois l'autorisation refusée.
1) Est-ce parce que j'ai monté le système de fichiers en utilisant salamis au lieu de www-data?
2) Est-il sécurisé de monter le système de fichiers sur Server 2 en tant que www-data? Si oui, comment puis-je y parvenir? www-data n'a pas de mot de passe et je ne peux pas me connecter avec su -m www-data. Je reçois authentication failure.
3) Pouvez-vous penser à une meilleure architecture?
SSHFS est un système de fichiers Fuse . Celles-ci sont gérées par un processus utilisateur qui s'exécute en tant qu'utilisateur qui monte le système de fichiers: le processus sshfs que vous exécutez sert également de pilote du système de fichiers. Par défaut, la plupart des systèmes de fichiers Fuse permettent uniquement à l'utilisateur du montage d'accéder aux fichiers qu'il contient.
Pour pouvoir accéder aux fichiers via sshfs, vous avez besoin de trois choses:
- L'utilisateur authentifié via ssh sur le serveur1 doit pouvoir accéder aux fichiers.
- L'utilisateur qui tente d'accéder au système de fichiers sshfs sur server2 doit disposer des autorisations d'accès nécessaires.
- L'utilisateur qui tente d'accéder au système de fichiers sshfs sur server2 doit être autorisé à accéder à ce système de fichiers.
Comme je l'ai écrit ci-dessus, seul l'utilisateur qui utilise cette version possède cette dernière autorisation. Vous pouvez vous détendre en ajoutant -o allow_user à la ligne de commande sshfs, mais cela ne résoudra pas les deux autres problèmes. Notez que -o allow_user ne prend effet que si /etc/Fuse.conf contient user_allow_user ou si vous exécutez sshfs en tant que racine.
Sur server2, vous devez exécuter sshfs en tant qu'utilisateur www-data (auquel vous devrez donner accès à la clé privée SSH), ou activer allow_user et prendre des dispositions pour que le www-data local ait accès aux fichiers dont il a besoin. Il existe plusieurs façons de le faire: via l'option uid, en passant -o default_permissions ou en passant -o umask 770,gid=www-data. Si vous activez allow_user, assurez-vous de ne pas autoriser www-data à accéder à plus de fichiers que prévu, et de ne pas autoriser les autres utilisateurs à voir ou à modifier ce qu'ils ne devraient pas. Exécuter sshfs en tant que www-data a l'avantage de la simplicité, vous avez de bien meilleures chances de ne pas être accidentellement trop permissif.
Pour le problème n ° 1, vous devez ssh dans le compte www-data sur server1 ou autoriser le compte que vous utilisez à accéder à ces fichiers. Il est avantageux de ne pas autoriser les connexions distantes à des comptes système, telles que www-data, car elles rendent l'audit de mauvaise qualité (vous ne pouvez pas savoir qui a réellement utilisé le compte). Cependant, ce n'est pas hors de question, et c'est un peu plus facile à mettre en place. Si vous ne souhaitez pas autoriser les connexions distantes au compte www-data, ajoutez salamis¹ au groupe www-data, assurez-vous que le système de fichiers sur server1 est monté avec l'option acl (ajoutez-le à l'entrée correspondante dans /etc/fstab si nécessaire), puis ajoutez-le. un ACL dans les fichiers de www-data:
setfacl -d -m group:www-data:rwx -R /path/to/www-root
setfacl -m group:www-data:rwx -R /path/to/www-root
¹ Si c'est votre compte sur server1, votre question ne dit pas si salamis était un utilisateur de server1, de server2 ou des deux.
1) Oui, tout comme Gilles a répondu, l’identifiant de connexion que vous utilisez est le propriétaire par défaut des fichiers créés. Ceci est vrai pour la plupart des protocoles.
2) Son correct, il n'y a pas de mot de passe pour l'utilisateur www-data. Vous pouvez cependant donner un mot de passe temporaire à www-data et copier le certificat salamis sur www-data avec la commande ssh-copy. Lorsque cela est fait, salami peut se connecter et se monter en tant que www-data sans entrer de mot de passe. (Vous devez avoir un certificat construit avec ssh-keygen.)
3) Une autre solution possible consiste à rsync les fichiers entre les deux serveurs. Rsync utilise la même infrastructure sécurisée que ssh/sftp/sshfs, vous pouvez utiliser ssh-copy exactement comme vous le faisiez dans 2. Avec rsync, vous pouvez laisser www-data récupérer les fichiers de salami. L'utilisation de ssh-copy vous donne la possibilité de créer un script pour la synchronisation, une ligne dans /etc/cron.[dayly|hourly] suffit dans la plupart des cas. Rsync est robuste, s'il y a un problème avec le serveur Salamis, votre application peut toujours fonctionner avec les derniers fichiers que vous avez synchronisés. Votre application n'est pas ralentie par le réseau, mais vous disposez d'un délai entre le changement de fichier dans Salamis. -directory et sur le serveur. Vous pouvez également envisager d'utiliser un VCS, par exemple bzr, et extraire vos fichiers d'un référentiel. Cela vous donne un contrôle de révision Nice de vos codes source.