vsftpd échoue à l'authentification pam


13

Déplacer une configuration vsftpd éprouvée sur un nouveau serveur avec Fedora 16, j'ai rencontré un problème. Tout semble aller comme il se doit, mais l'authentification des utilisateurs échoue. Je ne trouve aucune entrée dans aucun journal qui indique ce qui s'est passé.

Voici le fichier de configuration complet:

anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
idle_session_timeout=0
data_connection_timeout=0
nopriv_user=ftpsecure
connect_from_port_20=YES
listen=YES
chroot_local_user=YES
chroot_list_enable=NO
ls_recurse_enable=YES
listen_ipv6=NO

pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES

FTP me demande un nom d'utilisateur et un mot de passe, je les fournis, Login Incorrect. J'ai vérifié, cet utilisateur peut se connecter depuis ssh. Quelque chose est foutu avecpam_service .

Anonyme (si changé en autorisé) semble bien fonctionner.

SELinux est désactivé.

Ftpsecure semble être bien configuré ... Je suis complètement perdu!

Voici les fichiers journaux que j'ai examinés sans succès:

/var/log/messages
/var/log/xferlog      #empty
/var/log/vsftpd.log   #empty
/var/log/secure

J'ai trouvé quelque chose dans /var/log/audit/audit.log:

type=USER_AUTH msg=audit(1335632253.332:18486): user pid=19528 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="kate" exe="/usr/sbin/vsftpd" hostname=ip68-5-219-23.oc.oc.cox.net addr=68.5.219.23 terminal=ftp res=failed'

Je devrais peut-être regarder /var/log/wtf-is-wrong.help :-)

Plus d'infos:

/etc/pam.d/vsftpd ressemble à ceci:

#%PAM-1.0
session    optional     pam_keyinit.so    force revoke
auth       required     pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers onerr=succeed
auth       required     pam_shells.so
auth       include      password-auth
account    include      password-auth
session    required     pam_loginuid.so
session    include      password-auth

1
Quelle est la configuration PAM ( /etc/pam.d/vsftpdje pense)?
Gilles 'SO- arrête d'être méchant'

Essayez /var/log/syslogou dmesg.
Hello71

pam config: session facultative pam_keyinit.so forcer la révocation de l'authentification requise pam_listfile.so item = user sense = deny file = / etc / vsftpd / ftpusers onerr = réussir l'authentification requise .so session include password-auth
KateYoak

Réponses:


24

Ouf. J'ai résolu le problème. Cela revient à une configuration mais dans /etc/pam.d/vsftpd

Parce que les sessions ssh ont réussi alors que les sessions ftp ont échoué, je suis allé à

/etc/pam.d/vsftpd, a supprimé tout ce qui était là et a plutôt placé le contenu de ./sshd pour correspondre précisément aux règles. Tout a fonctionné!

Par méthode d'élimination, j'ai constaté que la ligne incriminée était:

    auth       required     pam_shells.so

Le supprimer me permet de continuer.

"Pam_shells est un module PAM qui n'autorise l'accès au système que si le shell des utilisateurs est répertorié dans / etc / shells." J'y ai regardé et bien sûr, pas de coup bas, rien du tout. C'est un bogue dans la configuration de vsftpd à mon avis, car nulle part dans la documentation vous n'avez édité / etc / shells. Par conséquent, l'installation et les instructions par défaut ne fonctionnent pas comme indiqué.

Je vais trouver où je peux soumettre le bogue maintenant.


/ etc / shells est généralement censé contenir une liste de shells acceptables. Il est utilisé par plusieurs sous-systèmes différents et devrait être correct. Ce fichier n'est pas créé ou maintenu par vsftpd, mais plutôt par la configuration de base de votre distribution. Ce n'est donc pas un bug vsftpd, c'est un bug avec la configuration de votre ordinateur.
tylerl

Dieu merci! J'aurais dû voir que l'utilisateur incapable de se connecter correspondait à ceux avec / sbin / nologin comme shell utilisateur ...
mveroone

Merci beaucoup! Votre commentaire sur /etc/shellsm'a aidé à trouver la raison de cet étrange changement de comportement. L'utilisateur FTP a été créé avec Shell: /sbin/nologinet /sbin/nologins'est avéré être supprimé de /etc/shells. J'ai donc ajouté les lignes /sbin/nologinet /usr/sbin/nologinqui ont auth required pam_shells.soaussi fonctionné.
Bodo Hugo Barwich

4

J'utilise Ubuntu et j'ai eu le même problème

Solution:

add-shell /sbin/nologin
sudo usermod -s /sbin/nologin ftpme
sudo vi /etc/pam.d/vsftpd

Ensuite, commentez et ajoutez des lignes comme suit

#%PAM-1.0
session    optional     pam_keyinit.so    force revoke
auth       required     pam_listfile.so item=user sense=deny file=/etc/ftpusers  onerr=succeed
auth       required     pam_shells.so
#auth       include      password-auth
#account    include      password-auth
#session    required     pam_loginuid.so
#session    include      password-auth
@include common-auth
@include common-account
@include common-password
@include common-session

0

Comme vous l'avez mentionné dans votre propre réponse, le shell utilisateur doit être répertorié dans /etc/shells. Vous pouvez définir /sbin/nologincomme shell utilisateur pour interdire ssh et autoriser ftp sans changer la configuration de pam:

usermod -s /sbin/nologin restricted_ftp_user

0

Si vsftpd échoue avec une erreur de

vsftpd.service: processus de contrôle terminé, code = état quitté = 2

Ensuite, une autre possibilité consiste à vérifier si elle pasv_addr_resolve=YESest définie dans le /etc/vsftpd/vsftpd.conffichier. Cela provoque la résolution du nom d'hôte du serveur FTP via DNS. Si DNS ne résout pas, comme si vous ne pouvez pas ping yourhostname.example.com, alors vous devrez résoudre ce problème de résolution DNS ou définir pasv_addr_resolve=NOle /etc/vsftpd/vsftpd.confet il devrait au moins laisser vsftpd démarrer sans l'erreur.


0

J'ai également rencontré le même comportement étrange lorsqu'un utilisateur FTP configuré avec

# finger <user>
Login: <user>                   Name: 
Directory: /home/user-dir           Shell: /sbin/nologin
Never logged in.
No mail.
No Plan.

sur un système peut se connecter et sur l'autre non.

Conformément à la réponse de @KateYoak, il s'est avéré que le /etc/shellsfichier était différent et n'incluait pas le /sbin/nologinshell. qui a fait l'authentification PAM en/etc/pam.d/vsftpd

auth       required     pam_shells.so

échouer

En ajoutant simplement au /etc/shellsfichier les lignes manquantes

/sbin/nologin
/usr/sbin/nologin

l'enregistrement a /etc/pam.d/vsftpdfonctionné.

Un /etc/shellsfichier de travail devrait donc avoir:

# cat /etc/shells
/bin/sh
/bin/bash
/sbin/nologin
/usr/bin/sh
/usr/bin/bash
/usr/sbin/nologin
/bin/tcsh
/bin/csh

0

dans mon cas, j'ai opté pour commenter la ligne d'authentification dans le fichier de configuration /etc/pam.d/vsftpd

#%PAM-1.0
session    optional     pam_keyinit.so    force revoke
auth       required     pam_listfile.so item=user sense=deny file=/etc/vsftpd/f$
#auth       required    pam_shells.so
auth       include  password-auth
account    include  password-auth
session    required     pam_loginuid.so
session    include  password-auth

Voilà la raison. Si vous ajoutez / sbin / nologin en tant que système shell, vous pourriez probablement ouvrir une porte dérobée indésirable dans votre système. Au lieu de cela, la modification de ce fichier n'affecte sûrement que vsftpd .

Je ne sais pas si un autre processus comme sshd recherche des shells système, mais je pense que changer le fichier pam.d est une meilleure solution que les autres.


-2

Sauvegardez le fichier de configuration avant d'apporter une modification;

sudo cp /etc/vsftpd.conf /etc/vsftpd.conf.back

puis éditez vsftpd.conf (avec vi ou nano)

nano /etc/vsftpd.conf

Effectuez ensuite la modification suivante

pam_service_name=ftp

Enregistrez votre modification et redémarrez le serveur ftp (si vous utilisez nano, appuyez sur CTRL + O et entrez pour enregistrer, puis CTRL + X pour quitter)

sudo service vsftpd restart
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.