Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
08-16-2003, 11:39 PM
|
#1
|
LQ Newbie
Registered: Aug 2003
Posts: 9
Rep:
|
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
|
|
|
08-17-2003, 07:26 AM
|
#2
|
Member
Registered: Jul 2003
Location: netherlands
Distribution: rh/debian
Posts: 43
Rep:
|
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?
|
|
|
08-17-2003, 02:52 PM
|
#3
|
LQ Newbie
Registered: Aug 2003
Posts: 9
Original Poster
Rep:
|
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
|
|
|
08-17-2003, 05:11 PM
|
#4
|
Member
Registered: Jul 2003
Location: netherlands
Distribution: rh/debian
Posts: 43
Rep:
|
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.
|
|
|
08-17-2003, 05:48 PM
|
#5
|
LQ Newbie
Registered: Aug 2003
Posts: 9
Original Poster
Rep:
|
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....
|
|
|
08-17-2003, 06:16 PM
|
#6
|
Member
Registered: Jul 2003
Location: netherlands
Distribution: rh/debian
Posts: 43
Rep:
|
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.
|
|
|
08-17-2003, 06:18 PM
|
#7
|
Member
Registered: Jul 2003
Location: netherlands
Distribution: rh/debian
Posts: 43
Rep:
|
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.
|
|
|
08-17-2003, 07:32 PM
|
#8
|
LQ Newbie
Registered: Aug 2003
Posts: 9
Original Poster
Rep:
|
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
|
|
|
08-18-2003, 01:18 PM
|
#9
|
Member
Registered: Jul 2003
Location: netherlands
Distribution: rh/debian
Posts: 43
Rep:
|
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
|
|
|
08-18-2003, 01:24 PM
|
#10
|
Member
Registered: Jul 2003
Location: netherlands
Distribution: rh/debian
Posts: 43
Rep:
|
"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.
|
|
|
08-19-2003, 06:52 PM
|
#11
|
LQ Newbie
Registered: Aug 2003
Posts: 9
Original Poster
Rep:
|
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?
|
|
|
10-27-2003, 10:38 AM
|
#12
|
LQ Newbie
Registered: Oct 2003
Location: Mexico
Posts: 1
Rep:
|
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.
|
|
|
10-29-2003, 01:43 AM
|
#13
|
LQ Newbie
Registered: Aug 2003
Posts: 9
Original Poster
Rep:
|
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.
|
|
|
All times are GMT -5. The time now is 03:08 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|