Security issue: Virtualmin user can use SSH

Hello again,

I have to create a Virtual Server and by default Virtualmin is creating an account for administration based on website name (e.g. -> mydomain and folder in /home mydomain).

I discovered this user could access the server using SSH, not only Virtualmin interface. This is not good at all. When a Virtualmin user doesn't make any effort to change the default administrator name like mydomain, he allows in fact a first step into penetrating the system: the username. Then it is a matter of password to get in.

I suggest all Virtualmin users who are not creating their own administrator names to pay attention to SSH authentication. They must insert the admin name (the domain name) into SSH configuration to deny it.

DenyUsers mydomain

In this way an attacker cannot use this intuitive name. Of course they can change port, use Fail2Ban, but why not cutting the attempts from the very beginning?

My suggestion is when you create a Virtual Server to have an option to deny that user in SSH configuration. This check box make it visible no one to skip it.

Thank you.



Howdy -- while it is intentional that SSH is enabled, users who don't want that can disable it by going into System Customization -> Custom Shells.

You can also setup password restrictions by going into Webmin -> System -> Users and Groups -> Module Config -> Users and Groups, and there, you can setup a variety of things such as "Minimum password length" and "Prevent dictionary word passwords".

By default, a Virtual Server owner can access the system via SSH, FTP, and through Virtualmin itself.

All of those offer the same permissions -- a user using SSH can see and edit the same files as a user using the Virtualmin filemanager. It also doesn't require SSH access to run commands. That can be done via Virtualmin, or a web-based file manager.

The thing preventing them from causing problems are the permissions setup on your server.

There is some additional information on there here in the section "How can I prevent other types of users from browsing the entire filesystem?":

When a Virtualmin user is using sftp it can browse the whole file system.

I read the faq from the link you mentioned but it is not covering this. Is it a way to keep this user only in his home directory when using sftp?

Please do the following steps:

1) Use Filezilla to connect to your server using sftp://

2) Use your virtualmin account to get access

3) You can browse you system. BUT YOU CAN CHANGE ROOT FILES! Go to /etc/ and edit hosts file. You can edit and save it.

It is clear to me a virtualmin administrator has too many rights inside this system and we must find a way to prevent such of security issues.

Please note in cPanel you cannot browse the file system even you use sftp connection (there are some settings inside /etc/ssh/sshd_config to be done). Virtualmin should have this feature too. For the moment I will restrict all virtualmin admin's to ssh.

By default, only the root user has the ability to edit files in /etc. No other user can do that.

The only way that would occur is if this user has root privileges, or if the files in /etc have been modified to allow additional users to edit them.

You may need to review the permissions of the files in /etc to ensure that's not the case.

However, for both SSH and SFTP, there isn't a chroot jail for them for the reasons described in the FAQ link.

That is, preventing them from accessing a file in SSH doesn't prevent them from accessing it via the website. So the real key is to make sure that permissions are set in a way that doesn't allow users to view or edit files they shouldn't be able to access.

1) With this options inside /etc/ssh/sshd_config I could jail a virtualmin account to /home directory. But as you can test it, I can go in others /home subdirectories.

Match User virtminuser

ChrootDirectory /home

AllowTCPForwarding no

X11Forwarding no

GatewayPorts no

ForceCommand internal-sftp

2) I will implement this tutorial which seems to solve the problem:

3) cPanel is not allowing browsing more than /home/{USER} directory, both ftp and sftp. We should get this feature inside Virtualmin

4) We should think about restricting a virtualmin account to browse the whole file system.


Am interested and subscribing to this to see if you'll be able to implement what you want.

I agree, this idea of putting on the system admin, the responsibility of the properly restrictive file permissions and ownership of the entire server, is probably too much to ask, in 2015. Many or most using Virtualmin, are amateur system admins and cannot properly police every single file and folder on their system. If they make one small mistake, which is easy to do, in permissions/ownership, the entire server or a large part of it, could be compromised, leading to costly data loss. This is relatively easy to prevent from the point of view of Virtualmin. Probably Virtualmin application itself would be best at applying "best practice world class level" secure default permissions and ownership, by default, to the entire server, so as to prevent information leakage, security breach, etc. This problem of leakage leading to much easier hackability of the server, was so huge and important, that Cpanel solved it for their customers by having created their own filesystem virtualization product called CloudLinux, it works by whitelisting only certain binaries, config files, folders, to allow these be accessed by users, via sftp and web/webdav. All others are forbidden. Sort of a chroot plus accessibility of certain whitelisted system conf files and binaries located otuside of the chroot jail. No user should be able to see contents of other user's files, or sensitive system files, even if it would be technically the "fault" of the system admin for not policing proper permissions and ownership. There is too much possible loss of value at stake.

@Chris_C: Good observation related to my concerns. Can you imagine I did not install sudo yet on this system? Giving root permissions can create too much trouble. I agree cPanel solution is what we must have for Virtualmin, some kind of chroot implementation. A Virtualmin use shouldn't browse the file system from Terminal or from Browser. A webmin user is completely different as behavior and in my opinion can allow to do that.

It is not up to me what is next in Virtualmin, but such of discussion what to the only one in the past ...

For those who are reading this issue, I don't want to restrict SSH access for a virtualmin user. This is good to have if you do not use FTP for uploading the files. It is only a problem of staying only in that home directory, /home/virtualmin_user. cPanel found a solution for this.

Thank you yngens. It seems this is a very long time request. Sorry to hear that. Unfortunately there is only two solutions I found in these posts, and none which come from Virtualmin developer team. Hope in 2015 to get a proper solution for this.

I found in those posts scponly was added in 2009, but without too many information. A chroot environment was in development according to Joe's post. What is the status of this implementation 6 years later? Thank you.

So, in theory we could implement SSH chroot restrictions for Virtualmin, so that domain owners logging in via SSH cannot see anything outside of their home directory.

However, the default permissions prevent users from accessing each others' home directories. Also, all critical files in /etc are locked down by default on all Linux systems to prevent access by non-root users. So I think that the security benefits added by an SSH chroot are minimal..

Diabolico's picture
Submitted by Diabolico on Mon, 10/05/2015 - 17:50

So I think that the security benefits added by an SSH chroot are minimal.. I cant agree with this. No sane host would allow anyone to get out of their /home and even listing other host (names) would be a security breach.

Other domain names are still going to be visible from files like /etc/passwd though, which are typically included in any chroot so that ls -l shows usernames properly.

In my case a virtualmin user can see other virtualmin user folder. Seeing the whole file system is not the big problem. Let's say a virtualmin user install Magento, in app/etc folder there is a file called local.xml. This file has inside precious information to access database in plain text.

Here is how they look like:

        <initStatements><![CDATA[SET NAMES utf8]]></initStatements>

This is one example of not allowing other users to see your files. You can set up permission for not reading, but what about virtualmin users? They are in the same group I guess. Having an implementation for SSH like in cPanel, just keeping the user in its home folder iwill give more security. except root, nobody should browser and see logs for example. I can do it right now with my virtualmin user. A virtualmin user is probably one who paid for having a share environment. I am not happy a strange person browsing my system. What about if this person is a hacker? He could find some information to exploit. As a conclusion Virtualmin needs chroot implementation as an option. Not the same thing for a webmin user which in my case is a clone of the root account which is administrated by one person, me.

Jamie, in fact, what you say (chroot including /etc/passwd) is no longer true on cpanel.

Around the year 2009, cpanel changed their chroot security model so that /etc/passwd is no longer included in chroot.

Therefore, since 2009, when I SFTP log in to my cpanel shared hosting account (equivalent to logging into a virtualmin virtual server), I no longer see username or group on my file and folder ownership.

Instead I see, in my case, user 503 and group 509.

Too bad for my visual convenience, but for the sake of security and privacy, it is more important that I not see my neighbor accounts and/or domain names (which is what I used to be able to see via the chroot having included of /etc/passwd), than to see my own account name.

It's really an issue of privacy...

I hope you can now see the privacy and security value of adding chroot environment for all user logins to the server (FTP, etc).

Here is an article from 2012 about manually setup SFTP + chroot on a time consuming painstaking basis inside Virtualmin.

However in the comments to the blog article above, on 4 days ago, Jim says he doesn't bother with SFTP (via SSH) and simply uses FTPS which is jailed automatically just like FTP.

This still doesn't get around the need to jail the SSH shell for "normal" users to keep from leaking sensitive privacy related information from system areas, such as, lists of other users and domains on the system, etc.

Seems like there are plenty of other ways that information about which domains and accounts exist on the system could still leak though - such as running processes, visible using the ps auxwww command.

Diabolico's picture
Submitted by Diabolico on Wed, 10/07/2015 - 02:03

What can be modified with other things like what is usually used in shared hosting.

Jamie, I agree you. But please see again my Magento example. I can view my neighbor information in web server directory. I changed permission to 600 but Magento stops working. Imagine someone who founds out I am using Virtualmin for sharing hosts, will buy an account and starting from that finding precious information about Magento databases. Once he gets login information he can dump the database, having all transactions, email addresses, possible credit card numbers if stored.

As it is Virtualmin built I can say all Virtualmin user accounts must be managed by the same person. If not there are some big security issues. Jailing virtualmin users is the only option to say cPanel is not better than Virtualmin.

So it absolutely should not be possible to access the directories of other domains - either via SSH or from a PHP script. The default Virtualmin install runs PHP scripts using fcgid, which runs them as the domain owner. The only exception to this case is if you switched domains to mod_php execution mode.


To say frankly, I don't understand why you are so much opposed against jailing regular users into their home directories. Even if there are other ways for really experienced hackers to get to sensitive information, it would be still nice to limit regular users form seeing other users' usernames, etc. I don't see any harm from providing minimum privacy and security implementation.

Maybe it complicate other things in Virtualmin and that's why you are reluctant to address this really really long going issue? If so say so. I mean your stance "there other ways to see sensitive information" does not justify refusing this request. It would be beneficial for Virtualmin to have a possibility to jail users within their home directories despite existence of whatever ways to see sensitive information.

I agree permissions could stop viewing or browsing the file system for a virtualmin user if you are an advanced administrator without creating trouble into your system. In my opinion just viewing the files tree is bad or allowing browsing for Virtualmin interface.

If we could get a chroot solution for virtualmin users it will be great, both cases file system and Virtualmin interface.

The reason I'm opposed is that it adds a lot of complexity to Virtualmin to maintain a chroot jail for each user - so support SSH logins, a whole bunch of commands and libraries have to be copied or bind-mounted inside the chroot. So unless there is a big security benefit from doing this, I'm not convinced that it is worth the extra complexity.

Also, for any SSH chroot to be effective, the chroot has to apply to CGI and PHP scripts as well - otherwise a domain owner can simply upload a script that displays the contents of /etc/passwd or whatever.

Joe's picture
Submitted by Joe on Thu, 10/08/2015 - 23:37 Pro Licensee

Sorry to dive in late in this thread...but I have strong opinions on this issue. ;-)

So, I hear folks frustration. And there's quite a bit of misunderstanding about what is currently easy to do, what is currently hard to do, and what a chroot would gain.

First up: default permissions on a Virtualmin system are much tighter than has been alluded to. If any user can see any other users data, the permissions on their home directory are definitely not defaults. It isn't hard to get permissions right...just leave them at the default.

Next up: I'm almost convinced it's worth making things tighter by default, but I'm still pretty certain chroot is not the right way to handle the goal of further tightening privacy on the system. SELinux probably is, and we would definitely consider adding more support for SELinux related features to Virtualmin.

It is already possible (very easily) to lock users into their homes in ProFTPd using DefaultRoot. And ProFTPd supports FTP over SSH, so it can be made the only method that users you want to restrict in this way login.

The thing about chrooting ssh is that it only prevents one method of seeing the file system. It sounds like cPanel has gotten somewhat more clever about their chroot build since I last researched it, but it doesn't alter the fact that it is a false sense of security. Short of giving every user a private chrooted Apache instance, there will be several methods of easily reaching the filesystem with whatever permissions web apps run with. If cPanel prevents that, I'd be curious about how. The ssh chroot has no relation to this and would not be how they're doing it.

I should probably look at a current cPanel system to get on the same page with what y'all are seeing and asking for. Last time I looked there were simple ways to see all of the information you can see on a Virtualmin system on a chroot enabled cpanel system (not via ssh, but via Apache, and other services that operated either outside of the chroot or within their own chroot with more access than users had). Y'all got one I can check out?

Joe's picture
Submitted by Joe on Thu, 10/08/2015 - 23:50 Pro Licensee

In short: I worry you're hearing us say "we don't want to make Virtualmin more secure or more respectful of privacy by default", but what we're really trying to express is "we don't want to make the same mistakes as cPanel or provide a false sense of security in doing so".

We can talk about ways to improve security. We just don't believe chroot is that way.

Joe's picture
Submitted by Joe on Fri, 10/09/2015 - 23:28 Pro Licensee

After sleeping on it, I'm looking into chroot shells again. Last time I looked into it there were serious security implications that made it such that it would have been irresponsible for us to make it an easy thing to setup (specifically, an exploit of the jail could lead to root escalation in the past; which is the worst possible outcome, especially for something that people believe provides "security"). That seems to no longer be a major risk, and privilege separation works alongside chroot with modern OpenSSH versions, so my biggest concern is not so much a factor any more.

I still worry at the belief that chroot provides significant security benefits in this context. But, it seems to be something that a lot of people want, so once the new website launches and the new major version of Virtualmin comes out (in a few days), I'll dig back into this issue.

I really appreciate for your work. If you can do this it will be great, I don't have a doubt. Too many people tried before solving this issue restricting virtualmin users to their home directories. SELinux or AppArmor are just fine, but a little bit complicated for average virtualmin users. chroot seems to be complicated because you start from the idea you have to put the libraries and binaries inside every virtualmin user. Will see how complicate it this.

Did you see that solution for Virtualmin?

What cpanel does to acheive this is with code they call cloudlinux, it's a file system driver that virtualizes the file system and returns contents of files but only if they're on a whitelist.

By doing this you save on all that wasted disk space of having to actually copy hundreds or possibly thousands of files into each virtual server account's chroot. The driver returns the contents of that one file as long as the system allows it.

Whatever files are essential are allowed.

Whatever compromises security (/etc/passwd , files in your neighbor's virtual server, the very existence of your neighbor's virtual sever, your neighbor's running processes, etc..) is non existent according to the file system driver, and therefore invisible to you.

This is like a "linked" chroot instead of an "embedded" chroot.