|
Quirky VSFTPD.CONF - cannot jail users
For some reason my vsftpd.conf file allows the system users, added using useradd and groupadd commands to browse other directories - even though I set the jailed option. Can anyone figure out what I did wrong in vsftpconf. I want clients to RW and browse just one directory! Its like vsftp auto logs into the root directory. Here’s how it looks:
Code:
|
Not sure. I'm not seeing anything that immediately jumps out as a culprit. Here's a running instance from a system I've setup that will chroot user to their defined home-dir and not navigate above it.
Code:
anonymous_enable=YES |
Thanks for the info Ray. I'm a little rusty. I haven't worked with groups or users in ages. I'm trying my best to follow the vsftp tutorials on youtube.com. Let me just say, that this is a real pain in the behind! It seems like there's a million and one steps involved with setting up an FTP server with ssl! Gone are the good old days of win9x when all we had to do was run app with a pretty GUI to select files. This is a nightmare! I typed groups on my system and I cant figure out why my user name is associated with so many god darn groups....I see admin, cdrom, samba, dip, lpaadmin, etc. I know that the system creates a group when a user is created. I don't get the purpose of defining all these groups...feel free to explain
|
You have not defined attribute local_root in your vsftpd.conf. It defines the path of the directory where you want to jail the user.
Jail means user can go to sub-directories but not in parent directories. User will log into this directory and can not go to the parent directory. Add this line in your vsftpd.conf Code:
local_root=/path/of/the/directory |
@eklavya hm interesting I'll try both suggestions as soon as I get a handle of user and group admin. I knew it was just a matter of setting the right attributes for the FTP. I wonder how this works with SSL. According, to the Ubuntu forums adding SSL security is just as simple.
|
You can enable vsftpd with virtual user to jail the user to home directory .Virtual users can therefore be more secure than real user
http://www.cyberciti.biz/tips/centos...ual-users.html |
Quote:
Examples:
|
@arun5002 Virtual users are meant for web admins according to the info online. It would require the installation of Apache web server. I'm looking for a minimalist approach.
awk -F":" '{ print "username: " $1 "\t\tuid:" $3 }' /etc/passwd | less lists all the users groups on my system....I can't make heads or tails out of it! very preplexing. cat /etc/passwd | grep "/home" |cut -d: -f1 lists the following users: syslog usbmux saned joe dummy i never created syslog,usbmux or saned. How can they possibly have home directories? |
Can someone pls explain the procedure of adding users to vsftp? I know that there're two types of users, virtual and system. I managed to set up a server and add an user using by following this guide. I don't want virtual users now, as it requires installation of Apache web server, which would bloat my system. After making a "fake shell" and configuring the vsftpconf file to jail users, I logged in as ftpuser. For some reason I cannot login as root or r/w to the jailed directory. How exactly does vsftpd keep track of users with this method? There's just too much info out there on the subject.
|
root and a handful of other usernames are not permitted login via ftp by default. The list of names are typically found in file /etc/vsftpd/ftpusers and/or /etc/vsftpd/user_list. This is because of the (default) clear-text nature of FTP leaving the root user's password freely obtainable to anyone along the path with even the slightest interest of capturing clear-text passwords.
If you are able to successfully authenticate via FTP for your user account, but unable to read the directory contents it is likely a filesystem permissions problem. Ensure the account has at least e(x)ecute permissions to all directories in the path to its home directory and at least (r)ead and e(x)ecute on its home directory. Code:
$ ls -ld /home/Code:
$ ls -ld /home/demo1/My first post contained a working example of a non-SSL enabled vsftpd configuration file that permits my local users the ability to login via FTP and be chrooted to their defined home directory. I am defining the term 'local users' as those created through the use of useradd (or adduser) and having a password set via passwd although it could be through various other mechanisms too, such as LDAP. I believe in your terminology used above that would be a 'system' user. If you're wanting a robust, feature-rich, SSL-enabled ftp server, my advice is to start slow and tackle one configuration objective (AKA: problem) at a time. Start with a working configuration that does what you want with what I'll call simple ftp (this is pretty much done right out of the box with a default vsftpd.conf), then enable local users and get that working how you desire, once that's completed, move on to the next step whether creating SSL certificates or otherwise. I'd advise performing the build-up with it not Internet facing until you are satisfied with your configuration to meet your intended objectives. Code:
$ sudo grep -v ^# /etc/vsftpd/vsftpd.conf Code:
$ sudo sed -i 's/\(chroot_local_user=\).*$/\1NO/g' /etc/vsftpd/vsftpd.conf |
@Rayford Now I see why root cannot login. Its not premitted in the files you listed! I had to manually configure the local_root option to local_root=home/ftp/, changing it from /home/ftp/$USER. VSFTPD failed to recognize the $USER variable, for some reason. Now I can login and it appears jailed (in other words I cannot nav above the user's home directory).
I can access the directory below the jailed ftp directory, which on my system is "ftpuser" - the acnt that I use to login. The problem that I'm trying to tackle at the momement is r/w permissions. Its like I have to use nautilus to allow "Others" to rwx to the "ftpuser" directory, 777. From my understanding, specificying such an option would allow anyone logged in to r/w to the ftpuser directory. I want just the "ftpuser" directory set to 700. So, no one else on the system or FTP server can modify the data in the ftpuser's directory. I'll try manually setting it to 700 through cmd line. As it stands now, it seems like I can write to ftp/ftpsuser/ and ftp/ when set to 777, although its jailed! |
If your user "ftpuser" does not own the directory then 700 will not permit that user to write to it when logged in via an ftp client. From the sounds of it, that might be the case. What does the output of 'ls -ld /home/ftp/ftpuser' report?
If it is not owned by ftpuser then you may try something like: Code:
$ sudo chown ftpuser /home/ftp/ftpuser |
@rayfordj Now it actually works. I can r/w the to just the ftpuser directory! All I had to was execute the two cmds you listed.
Here's the oput of the ls -dl cmd before chmod/chown was invoked Quote:
drwxx-------- 2 ftpuser root 4096 ..... I really have to brush up on chown and chmod. Its time to tackle SSL...thanks in advance Ray! |
Configuring SSL seems pretty trivial according to the docs online. I checked previous posts on this forum regarding the umask option, which apparently defines file permissions to uploaded files on the remote system. The default is 077. What difference does it make now that I'm NOT allowing anonymouse users? I want the same file permissions set on the remote machine. Would I have to change this particular attribute?
The docs also suggest connecting from port 20. I thought the default for FTP was port 21, unless passive mode is enabled to circumvent firewall settings on the remote machine. On my server, nmap localhost, shows that its set to port 21. Any idea why the suggested port 20? |
| All times are GMT -5. The time now is 06:52 PM. |