I prefer to keep FTP and SSH users separate. I don't want FTP users (an unencrypted protocol) to be able to access an SSH shell or the Virtualmin/Webmin interface, and I don't want SSH/Webmin users to be able to inadvertently use FTP and risk exposing their login and data to an unencrypted session.
Is this configuration possible in Virtualmin? I see where you can make an admin user FTP-only, but I don't see how to make that a default. And I don't see how to limit FTP access to unprivileged users. I.e., full admins always seem to have FTP access.
This seems like it should be basic functionality. How can this be set up in Virtualmin?
Thanks!
You can use pure-ftpd instead of proftpd and force this daemon to only accept SSL connections. I'm a long-time fan of pure-ftpd, probably the best ftp server available ;-)
Not to discourage use of Pure-FTPd, as it is reportedly a fine FTPd, but ProFTPd can also only accept SSL. Just set the "TLSRequired" option to "on". All done.
--
Check out the forum guidelines!
The latter would be as easy (or as complicated) as adding a new user but with same uid, gid and home directory <- this is the method which is independent of what FTP server is used. Alternatively, when such situations arise (multiple users with acces to same directory), one can use pure-ftpd's virtual users feature.
<div class='quote'>This seems like it should be basic functionality.</div>
Hehehe...You're making assumptions about how things operate that aren't quite reflected by reality. ;-)
<div class='quote'>Is this configuration possible in Virtualmin? I see where you can make an admin user FTP-only, but I don't see how to make that a default. And I don't see how to limit FTP access to unprivileged users. I.e., full admins always seem to have FTP access.</div>
The way FTP users are defined is by their shell, just like ssh users. So, to prevent a user from using ssh, but allowing FTP, you give them a shell that is listed in /etc/shells, but doesn't actually do anything...like /bin/false. The tricky thing is that if the shell isn't listed in /etc/shells, you can't (easily) choose it for a user in Virtualmin, so all users will get FTP access if they have any kind of access (so, ssh automatically grants FTP, though FTP doesn't grant ssh).
The best way to workaround that problem would probably be to make use of ProFTPd's "DenyGroup" directive, and setup Virtualmin to automatically add all virtual server administrators to this denied group. You can create a new "noftp" or "ftpdenied" or whatever group in the Webmin:System:Users and Groups module.
Adding new virtual server administrative users to a group can be done in the Module Configuration in the "Server administrator permissions" section, in the field labeled "Add all server administrations to Unix group". Existing virtual server administrators can be added to your new "noftp" group using the System:Users and Groups module, or by directly editing /etc/group.
--
Check out the forum guidelines!
Since posting the original question, I have dug into this and discovered most of what is suggested here.
My original intention was to mirror the setup I have manually done before, which is to have an admin user for a domain that can use an SSH shell but not ftp, and then one or more ftp users that can manage the public_html space (with group write permissions). The idea being that insecure ftp logins can't find their way to an SSH shell.
Virtualmin doesn't make that possible, really, due to its permissions scheme. Virtualmin makes the assumption that there is one admin user that can do both ftp and ssh, or can be limited to just ftp.
I suppose I can live with that, and just set things up that way instead.
I would suggest, however, that it makes sense to be able to configure Virtualmin to limit admins to ftp-only by default, so one doesn't have to remember to set this for each admin if one doesn't want to allow shell access. Unless I'm mistaken, this isn't possible.
In some ways I think it would make sense to have Virtualmin be able to have multiple admin logins for a domain, all able to edit the public_html space. But, I can see why this would probably needlessly complicate the interface.
Thanks for the replies.