vsftp 1.1.2 on redhat 7.1 -- 530 incorrect login issue
 

HI,
I'm running vsftp 1.1.2 on redhat 7.1 through xinetd. I can login anonymously no problem. when I try to login as a normal user I get a 530- incorrect Login error. I know the password is correct but I keep getting the Incorrect login message no matter what user/password I login with. I have scoured the web for the answer to no avail. Can anyone help me out?

FYI- I have "one_process_model=YES" commented out in my vsftpd.config as my kernal does not seem support this

Could be a couple of things. The most important thing to know is that a lot of FTP daemons check /etc/shells to see if the users shell is listed. If not, access is denied. So check your shell in /etc/passwd and make sure the /path/shell is in /etc/shells.

The "one_process_model" is off by default, besides that it has nothing to do with security.

Does /var/log/messages say anything about this?

shell is disabled for xinetd
 

Thanks for the help,
I checked out the /etc/passwd /bin/ftpuser is the shell path set for the user i am trying to login with. /bin/ftpuser is present in the /etc/shells file

I checked out /var/log/messages and something curious came up:

AUG 17 10:40:48 developer xinetd[11019]: shell disabled, removing

other than that Xinetd started and is running fine with vsftpd

Do I need to enable shell with xinetd? If so how can I do this? I see no reference to shell in the xinetd.conf

Well, /bin/ftpuser is not on my RedHat system. Is it on yours? If not, that's a pretty good reason for vsftpd to disable the shell. :)
You could try replacing it with /bin/bash or even better /bin/true.

I read somewhere that pointing the shell path for a user to a non-exsistant directory will simply make the user invisible to the gui(kde) login process. Regardless changing the shell path to /bin/bash or bin/true did not fix it. I figured out how to enable shell for xinetd and that didnt help either. Could it be a group thing? do the users have to be a member of a certain group to correctly login to the ftpd? It really seems like the ftpd is not checking the password for the user correctly, when I check the password for the users in the user manager the field always has four asterisks, eventhough I know the password has more. very strange....

Sorry, the /etc/shells tip is working on HP-UX but not on Linux :)

To enable normal users to log in with vsftpd, you have to set "local_enable" to YES in the vsftpd.conf file. Best thing to do is read the "man vsftpd.conf" page carefully. There are more interesting options concerning local users and anonymous access.

Under Linux, setting the users home to a non-existent directory will work fine with vsftpd. I'm using /dev/null as the homedir of FTP users who I don't want snooping around on my system.

The vsftpd option chroot_local_user=YES is pretty cool as well.

sigh-
I've read the documentation for vsftpd.conf very varefully. Im pretty sure its not my config. Its an authorization problem. I'll give the config another look before I email chris evans..
thanks

I've been reading and thinking through my ass! The /var/log/messages file is pretty clear about your problem; xinetd disables the "shell" before it allows vsftpd to do anything. So logically we should look at xinetd problems. You said you checked /etc/xinetd.conf for a "shell" statement - did you check /etc/xinetd.d/ as well?

My vsftpd file in /etc/xinetd.d looks like this:
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/vsftpd
server_args = /etc/vsftpd/vsftpd.conf
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
disable = no
}
vi

"shell disabled, removing" is just a normal statement. It means that xinetd has found an entry in one of its configuration files wherein "shell" is disabled, or it could not find any entry regarding "shell". Most commonly "shell" is referring to rsh, so it has nothing to do with ftp.

Well I looked further and saw that kwuftpd is installed, I dont think its running, because when I disable vsftpd port 21 closes. But maybye just having it installed keeps vsftpd from using the /etc/passwd to authenticate login. Is there a way to check is vsftpd is accessing the /etc/passwd file when I try to log in?

Hi triggerfish,
I'm having the same problem with vsftpd, I've also written Chris, but I haven´t received any answer from him yet, I don't now if you have received answer from him or if you have already solved this problem, if so could you please share the solution. Thanks
Best regards.

Actually, I solved the problem by using ssh. I had to give up on vsftpd. If you ever find a solution please post it, I would rather use ftp than sftp.