Vsftpd trouble, at a total loss

konkorfour · 02-23-2013, 11:25 AM

I'm sorry my first post is asking for help but I have no idea what is wrong.

I've set up Apache, PHP, mySQL, PHPMyAdmin and VSFTPD, I set the user "ftp"'s home directory to /var/www/ and using sudo su I set it to 777 just to test for now. I've got the following lines active in my /etc/vsftpd.conf file:

Code:

listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=NO
chroot_local_user=YES
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/private/vsftpd.pem

Now, when I first installed VSFTPD with the default settings I could connect and view the one index.html file but I could not delete or upload, after changing the settings to those above I can't even login... The username and password are correct but it says:

Code:

Status:	Connecting to 192.168.0.2:21...
Status:	Connection established, waiting for welcome message...
Response:	220 (vsFTPd 2.3.5)
Command:	USER ftp
Response:	331 Please specify the password.
Command:	PASS ***********
Response:	530 Login incorrect.
Error:	Critical error
Error:	Could not connect to server

However setting anonymous_enable=YES lets me view the directory but now instead of going to /var/www/ like it used to I just go to /

I've never used VSFTPD before so I'm kind of lost here, I've tried searching but the things people have said to try either make it worse or just don't help. So does anyone have any clue how I can just set the ftp user to read/write/delete anything in the /var/www/ folder and to work properly?

konkorfour · 02-23-2013, 12:46 PM

Okay so reading the log it says I'm logging in anonymously even though I'm using a user/pass.

konkorfour · 02-23-2013, 04:41 PM

So leaving anonymous_enable=YES, I can login and see the files for now. But I can't edit anything...

I've tried:
chown -R ftp /www/var/
chmod 777 /www/var/
write_enable=YES

Still nothing, not sure what is wrong.

I get Response: 550 Permission denied.

Hangdog42 · 02-24-2013, 09:13 AM

Quote:

, I set the user "ftp"'s home directory to /var/www/

Can this user even log in normally? On a lot of system the user 'ftp' is a really non-privileged user without login permission. You can only su into the account. So maybe we back up one step, just what tasks are you trying to accomplish?

konkorfour · 02-24-2013, 10:00 AM

Quote:

Originally Posted by Hangdog42

Can this user even log in normally? On a lot of system the user 'ftp' is a really non-privileged user without login permission. You can only su into the account. So maybe we back up one step, just what tasks are you trying to accomplish?

No because it's set to /bin/false, I've removed Vsftpd though I was getting too many problems with it so I switched to proftpd instead and it's working great now.

Hangdog42 · 02-24-2013, 10:19 AM

Quote:

Originally Posted by konkorfour

No because it's set to /bin/false

Glad you found a solution. For future reference, this is likely why trying to connect as the FTP user didn't work. VSFTPD was doing what it was supposed to do.

konkorfour · 02-24-2013, 12:13 PM

Quote:

Originally Posted by Hangdog42

Glad you found a solution. For future reference, this is likely why trying to connect as the FTP user didn't work. VSFTPD was doing what it was supposed to do.

What was it supposed to do? I had tried the default created ftpuser that's made by the app, I tried my username, 2 created ones and one that I created using a guide specifically for Vsftpd.

Hangdog42 · 02-24-2013, 01:22 PM

Any user that doesn't have the ability to log in shouldn't be able to get in via FTP either. So the fact that 'ftp' was set to /bin/false should mean that if you try to connect as 'ftp' it should fail. To use FTP, the user logging in has to be able to use/create a shell and ftp clearly can't. Users like that are created as a security measure so that the FTP server isn't running as root, and if it is compromised, the attacker has no privileges.

However, a real user (presumably your username) SHOULD have been able to connect and get into a directory. Looking at your config file in the first post may be a place where this went wrong. The 'chroot_local_users' is finicky. If the users "root" dir is writeable (/home/user), vsftp will shut down the connection. That may have been what you were intending to get around with the chroot_list file, but I can't tell. You can also use the 'allotw_writeable_chroot=YES' to get around this as well. That is more global than the chroot_list and should be used with care.