I think the following is a common setup these days: You have a webserver and host websites for a couple of friends. Your friends don’t need shell access, but they need FTP.

Now, vsftpd is the FTP server of choice for such a situation: It is light-weight, and as it relies on system features (namely PAM) for user authentication, it can be considered quite secure in regard to user management – as opposed to FTP servers that feature their own authentication layer. Vsftpd can, as most FTP servers, chroot users into their home directories, meaning they cannot access other parts of the server below their home directory.

In order to create a user account which can log in via FTP, but not SSH, you can use the following (as root):

useradd -d /path/to/website/document/root/ -s $(which nologin) username
passwd username

You can also switch the user’s shell later, if the account already exists:

usermod -s $(which nologin) username

The important thing is that the output of which nologin is a path to the nologin tool, which simply tells the authentication layer that it must not open an interactive shell, but issue an error and return a error code instead.

If you experience that a user gets an error from vsftpd if the shell is a normal interactive shell like /bin/bash, but they cannot log in if the shell is something like /usr/sbin/nologin, you must check if the correct path to the nologin tool is included in /etc/shells. If it’s not, you must add it here.

Now your users can enjoy the full comfort of an FTP server, and you don’t have to be afraid that their accounts can be misused to get shell access and snoop around on your server.

When you replace a comprehensive file tree via FTP, you will realize that it takes some time to do all the uploading. If your upload is going to replace old content, then one would usually first delete the old content, then upload the new one. (It is not a good idea to let the FTP client overwrite old contents, unless one knows exactly how the client behaves. For example, some clients merge existing trees, not deleting old files that are expunged rather than replaced, thus potentially raising security problems.)

However, the procedure of first deleting and then copying can leave your site naked or uncomplete for a couple of endless minutes. In the worst case, a user retrieves a page from your incomplete site and causes a database corruption or messes up the internal settings (this is not too unlikely with CMS applications). Therefore, the better way is to first upload the new content under a different name and then rename folders.

For example, if your web documents are in /var/www/docroot/, you would usually do the following: You delete everything in that directory and then upload the new content — which has the above mentioned side effects. Instead, you should better do the following: Upload all new content to /var/www/docroot_new/, rename /var/www/docroot/ to /var/www/docroot_old/, finally rename /var/www/docroot_new/ to /var/www/docroot/. Afterwards, you can delete /var/www/docroot_old/. Renaming is very fast, as only the base directory’s name has to be changed in the filesystem.

With this method, your website will only be naked for a few seconds, and there won’t be an incomplete installation at any time.