Ouvrez /etc/selinux/config
Remplacez selinux=enforcing ou permissive par désactivé.
Pensez à redémarrer le serveur !
Bien entendu, vous devez également déterminer les questions suivantes :
1. L'utilisateur ne peut-il pas se connecter par vsftpd ? Par exemple, le nom d'utilisateur est dans /etc/ftpusers et sa connexion est bloquée.
2. L'option d'authentification pam est-elle activée dans vsftpd.conf (je fais souvent des erreurs lorsque je la compile et l'installe moi-même) (Voyez s'il y a pam_service_name=ftp ou vsftpd dans vsftpd.conf. De quoi il s'agit dépend
Qui se trouve sous le fichier de service /etc/pam.d du module PAM ? Le mien est ftp et sa configuration est la suivante :
#%PAM-1.0
auth requis /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
authentification requise /lib/security/pam_unix.so shadow nullok
authentification requise /lib/security/pam_shells.so
compte requis /lib/security/pam_unix.so
session requise /lib/security/pam_unix.so
Si certains utilisateurs dans /etc/ftpusers seront refusés
3. Les autorisations des dossiers concernés sont-elles correctes ?
Concernant le problème de "certains utilisateurs locaux ne peuvent pas se connecter à vsftpd, mais d'autres le peuvent",
Aucun des comptes locaux existants dans le système ne peut se connecter. La configuration de mon fichier /etc/vsftpd/vsftpd.conf est la suivante :
local_enable=OUI
write_enable=OUI
chroot_local_user=OUI
pam_service_name=vsftpd
/etc/pam.d/vsftpd existe et est normal.
Le message d'erreur lors de la connexion est le même :
500 OOPS : impossible de changer de répertoire :/home/xxxx
La connexion a échoué.
421 Service non disponible, le serveur distant a fermé la connexion
Leurs répertoires personnels sont tous /home/xxxx. Les autorisations de /home et /home/xxxx sont toutes deux 755.
Aucun des comptes ci-dessus ne peut être connecté via FTP. Ceux-ci sont couramment utilisés et peuvent être connectés à l'aide du shell.
J'ai créé un nouveau compte usr1
# useradd -G test -d /tmp/usr1 usr1
Peut se connecter via FTP et son domicile est /tmp/usr1, qui se trouve sur la partition /. J'ai monté /home sur /dev/hda9.
#monter
/dev/hdb1 sur/type ext3 (rw)
/dev/hda9 sur /home tapez ext2 (rw)
Donc, je suppose : est-ce à cause de la partition /home que les « comptes dont le répertoire personnel se trouve dans la partition /home » ne peuvent pas se connecter ?
Afin de vérifier l'hypothèse ci-dessus, j'ai essayé de créer un autre compte
useradd -G test -d /home/usr3 usr3
Les autorisations de /home et /home/usr3 sont toutes 755.
La connexion FTP usr3 a échoué.
500 OOPS : impossible de changer de répertoire :/home/usr3
La connexion a échoué.
421 Service non disponible, le serveur distant a fermé la connexion
À ce stade, je pense qu'il est certain que c'est à cause de la partition /home que le "compte dont le répertoire personnel se trouve dans la partition /home" ne peut pas se connecter.
Article de référence :
J'ai terminé ma deuxième mise à niveau vers Fedora Core 4. Bien sûr, tout n'est pas encore réglé avec la version, mais une chose est sûre, il est arrivé beaucoup de choses à la RedHat que je connaissais auparavant.
Je dois dire que parmi tous les changements, pour moi, l'ajout le plus intéressant est les nouvelles extensions SELinux. Pour obtenir des informations approfondies sur les raisons et la théorie de SELinux, lisez L'inévitabilité de l'échec : l'hypothèse erronée de la sécurité dans les environnements informatiques modernes.
Plus je travaille avec SELinux, plus je réalise que j'ai besoin d'en savoir plus sur lui et sur la façon dont il fait exactement tout son travail. Cela change certainement les choses concernant les utilisateurs, les répertoires et l'accès, à mesure que je commence à l'apprendre, j'en suis sûr. Je fais les choses à la dure :)
La principale différence, jusqu'à présent, dans SELinux de Red Hat est la façon dont ftp est géré. vsftpd est toujours le serveur qui est génial. Cependant, il semble être conçu pour fonctionner comme un démon plutôt que d'être invoqué via xinet.d. vous récupérez une copie de travail du fichier xinet.d pour vsftpd, vous pouvez l'invoquer via le wrapper xinet.d. J'ai effectué ma première mise à niveau de serveur de cette manière. Celle que j'essaie actuellement en tant que démon, je pense certainement que j'en manquerai. des fonctionnalités apportées par le wrapper xinet.d, et peut encore y revenir.
De tous les problèmes que j'ai vus, le plus notable est celui si vous souhaitez activer le répertoire chroot en dehors du /home/xxx vsftpd normal. Ceux-ci échoueront avec un.
500 OOPS : impossible de changer de répertoire : /mnt/xxxxx
J'ai pu utiliser FTP si je me suis connecté avec un compte avec un répertoire dans /home, mais une fois que j'ai défini un compte utilisateur pour avoir un lecteur personnel en dehors de /home (dans ce cas sur un disque secondaire monté), vsftpd barfs ce qui précède .
J'ai trouvé des informations auprès de la NSA indiquant que vous pouvez désactiver la protection SELinux du démon ftp.
setsebool -P ftpd_disable_trans 1
Cela semble un peu radical, mais cela fonctionne certainement pour le moment.
Je pense qu'en fin de compte, le problème réside dans les politiques, mais comme les politiques SELinux sont nouvelles pour moi, il faudra du temps avant que tout soit réglé. Au fur et à mesure que je passe du temps avec les nouvelles extensions SELinux dans Fedora Core 4, je vous tiendrai au courant de mes réflexions. et des cours de configuration.
Solution:
# setsebool ftpd_disable_trans 1
# redémarrage du service vsftpd
J'utilise FC4 et j'ai essayé la méthode de votre message précédent, et le problème a été résolu immédiatement. Par conséquent, on peut déterminer que la cause réside dans SELinux.