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
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 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.
Method 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
Method 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.
Method 4
As you mentioned in your own answer, the user shell should be listed in /etc/shells. You could set /sbin/nologin as user shell to forbid ssh and allow ftp without changing pam configuration:
usermod -s /sbin/nologin restricted_ftp_user
Method 5
If vsftpd fails with an error of
vsftpd.service: control process exited, code=exited status=2
Then another possibility is to check if
pasv_addr_resolve=YES is set in the /etc/vsftpd/vsftpd.conf file. This causes the hostname of the FTP server to be resolved via DNS. If DNS won’t resolve, like if you can’t ping yourhostname.example.com, then you’ll need to fix that DNS resolution problem or set pasv_addr_resolve=NO in the /etc/vsftpd/vsftpd.conf and it should at least let vsftpd start without the error.
Method 6
I also ran into the same strange behaviour where a FTP-User configured with
# finger <user> Login: <user> Name: Directory: /home/user-dir Shell: /sbin/nologin Never logged in. No mail. No Plan.
on one System is able to log in and on the other not.
In extention to the Answer of @KateYoak it turned out that the /etc/shells File was different and did not include the /sbin/nologin shell.
which made the PAM Authentication in /etc/pam.d/vsftpd
auth required pam_shells.so
fail
By just adding to the /etc/shells File the missing lines
/sbin/nologin /usr/sbin/nologin
the check in /etc/pam.d/vsftpd worked.
So a working /etc/shells File should have:
# cat /etc/shells /bin/sh /bin/bash /sbin/nologin /usr/bin/sh /usr/bin/bash /usr/sbin/nologin /bin/tcsh /bin/csh
In more recent Versions (Centos8) the /etc/shells only contains:
# cat /etc/shells /bin/sh /bin/bash /usr/bin/sh /usr/bin/bash
and User Accounts in those Systems are created with the /usr/bin/false Shell:
# cat /etc/passwd|grep -i ftp_user01 ftp_user01:x:1004:1004:FTP Account for user01:/home/user01:/usr/bin/false
Even though this configuration will not give automatically FTP Login what way.
$ ftp ftp-server02.domain.com Connected to ftp-server02.domain.com (ip.add.re.ss). 220 FTP Service of Server ftp-server02 Name (ftp-server02.domain.com:local_user02): ftp_user01 331 Password required for ftp_user01 Password: 530 Login incorrect. Login failed. Remote system type is UNIX. Using binary mode to transfer files.
It is always required to insert /usr/bin/false into /etc/shells
So the Minimum Configuration to get the FTP working should be:
# cat /etc/shells /bin/sh /bin/bash /usr/bin/sh /usr/bin/bash /usr/bin/false
Site Note about the thought from @Greeso :
The man pages on /sbin/nologin explain:
man page nologin:
nologin displays a message that an account is not available and exits non-zero. It is intended as a replacement shell field to deny
login access to an account.
nologin is a per-account way to disable login (usually used for
system accounts like http or ftp).
So actually running the /usr/sbin/nologin Command it displays:
$ /usr/sbin/nologin ; echo "res: '$?'" This account is currently not available. res: '1'
So bots that try a bruteforce attack on the system and get this message can use it to conclude that the Account exists in the System and that the Login is for a FTP or HTTP Service.
So you can understand the change as a strategy to harden the System Security.
Method 7
Back up the config file before making a change;
sudo cp /etc/vsftpd.conf /etc/vsftpd.conf.back
and then edit vsftpd.conf (with vi or nano)
nano /etc/vsftpd.conf
Then make the following change
pam_service_name=ftp
Save your change and restart the ftp server (if you use nano hit CTRL+O & enter to save then CTRL+X to exit)
sudo service vsftpd restart
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0