Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
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.
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.
So I'm trying to setup a secure FTP server. I'm not really sure what the standard setup/procedure is for this. It seems to me that the Linux file permissions are quite difficult to setup in a way that prevents logged on users from browsing around and reading things that maybe they shouldn't. I'd like to have a clean and simple environment for the users, where they just see what they need to, and nothing else. I tried to chroot them to their homes, but then found that symlinks can't get you outside either. I have areas of my filesystem that I want them to have access to, that would be unsuitable to, and far to large for, an ftp user's home directory. So all I can think of is to have a regular login to the home, with the symlinks that I want, and to setup strange and annoying file permissions all over my filesystem. Is there some great way to do this that I don't know about?
I'm also curious about the encryption. As I understand it, using SFTP through SSH encrypts everything, including the data transferred. This is what I want. However, I was reading some documentation for PureFTPd, and it mentioned that it only encrypted the logins and commands, not the data. I'm wondering if this is a universal difference between SSH and the regular FTP daemons with SSL/TLS support.
Finally, I'd just like to know what the most common procedures are for this, and what servers are recommended.
SFTP: ftp over ssh, everything is encrypted
FTPS or FTP/ssl:ftp over ssl, the control connection is encrypted. The data connections are not always encrypted. Check your server documentation.
If you have openssh, sftp probably already works, give it a try.
Most ftp servers allow you to jail a user in his home directory. Check your server documentation. I don't think Openssh/SFTP can do this, as the user must have an account with ssh shell access anyways, which can't really be jailed. It would be pointless to restrict him in sftp mode and let him see the files in ssh.
Alright, so not all FTPS servers encrypt the data. Good to know, I'll have to make sure of that, then. Or I'll just use SSH.
SFTP does work over SSH. My problem is what to do now. I did set it up so the user was chrooted to their home directory (jailed, as you say). It was a lot of work, just to find out that this won't work for me. You have to put the essential shell environment files in their home directory, basically. But you also need a specially compiled, and patched, SSH for it to work properly.
As I mentioned in my first post, I don't want to chroot (jail) the users to their home. I have some areas of my filesystem, that are very large, that I don't want residing in that user's home directory. I was hoping that symlinks could get them out of their homes, just to these specific folders, but they can't.
I'd like to know how people setup their ftp servers, if they don't chroot users to their homes. It just doesn't seem right for ftp users to have the ability to peruse your entire filesystem. Chroot can't be the only way to prevent this. Even IIS has a simple mechanism for virtual hosts that link to a specific folder and don't allow users outside of it. The only way that I can think of, to mimic this in linux, would be to have a user for each one of these folders, and to make those folders their home directories. That's just silly. :P
For obvious reasons, you can't leave a chroot. proftpd gives you some suggestions:
Quote:
Symlinks will not work from within a chrooted area. The reason should be clear from a casual inspection of the nature of the chroot command. It is not possible to have a symbolic link to a directory which can"t be reached beacuse it's outside of the current chroot. Work arounds to allow access to other parts of the file system include exporting the part of the filesystem to be accessed from inside the chroot and mounting via NFS, using hard file links or (on Solaris) using lofs to mount the directory via the loopback.
mount -Flofs /home/data1 /ftp/data1
mount -Flofs /home/data2 /ftp/data2
As of the 2.4.x Linux kernel tree it is possible to mount filesystems multiple times and to mount subdirectories of filesystems elsewhere on the filesystem.
Since Linux 2.4.0 it is possible to remount part of the file hierarchy
somewhere else. The call is
mount --bind olddir newdir
After this call the same contents is accessible in two places.
Omg, thank you Stefan. That worked for me, and will be perfect. I was just coming back here to see what the arguments were for the "Flofs" one so I could get on with troubleshooting why it wasn't working for me. Now I don't have to, thank you.
Be careful: with too many users, I think you can run out of mountable filesystems (I think you can only have 255 mounted filesystems or something like that), but I am not sure.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.