vsftpd fails pam authentication

Question

Moving a tried-and-true vsftpd configuration onto a new server with Fedora 16, I ran into a problem. All seems to go as it should, but user authentication fails. I cannot find any entry in any log that indicates what happened.

Here is the full config file:

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 challenges me for a username and password, I provide them, Login Incorrect. I have verified, this user is able to login from ssh. Something is screwed up with pam_service.

Anonymous (if changed to allowed) seems to work well.

SELinux is disabled.

Ftpsecure appears to be configured fine... I am at a complete loss!

Here are the log files I examined with no success:

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

Found something in /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'

Perhaps I should look at /var/log/wtf-is-wrong.help :-)

Further info:

/etc/pam.d/vsftpd looks like this:

#%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

Solution 1

Whew. I solved the problem. It amounts to a config but within /etc/pam.d/vsftpd

Because ssh sessions succeeded while ftp sessions failed, I went to

/etc/pam.d/vsftpd, removed everything that was there and instead placed the contents of ./sshd to match the rules precisely. All worked!

By method of elimination, I found that the offending line was:

    auth       required     pam_shells.so

Removing it allows me to proceed.

Tuns out, "pam_shells is a PAM module that only allows access to the system if the users shell is listed in /etc/shells." I looked there and sure enough, no bash, no nothing. This is a bug in vsftpd configuration in my opinion as nowhere in the documentation does it have you editing /etc/shells. Thus default installation and instructions do not work as stated.

I'll go find where I can submit the bug now.

Solution 2

I am using ubuntu and had same issue

Solution:

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

Then comment and add lines as following

#%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

Solution 3

in my case I opted for comment the auth line in the /etc/pam.d/vsftpd config file

#%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

Here you are the reason. If you add /sbin/nologin as a shell system, you probably could open an unwanted backdoor in your system. Instead, changing this file surely you only affects vsftpd.

I don't know if another process like sshd looks for system shells, but I think changing pam.d file is better solution than others.

Comments

[Gilles 'SO- stop being evil']

What's the PAM configuration (/etc/pam.d/vsftpd, I think)?

[Hello71]

Try /var/log/syslog or dmesg.

[Ryan Walkowski]

pam config: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

[mveroone]

God thanks ! I should've seen that user unable to log in matched those with /sbin/nologin as user shell...

[Bodo Hugo Barwich]

Thank you so much! Your comment about /etc/shells helped me to find the reason for this strange behaviour change. The FTP-User was created with Shell: /sbin/nologin and /sbin/nologin turned out to be removed from /etc/shells. So I added the lines /sbin/nologin and /usr/sbin/nologin which made auth required pam_shells.so work too.

[Greeso]

Although this works, I am wondering if this causes a security problem! I am not sure, but there might be a good reason that the 'nologin; shells were not included in the shells

[Bodo Hugo Barwich]

@gree This was a good point about why this change was done. The nologin Command does still exist on all Linux Systems because it is part of the Kernel. But from the man pages I understand that it was considered to give to much information out. See my Edit for details.