Granting shell access for third-party with reasonable security

Hi community,

I’m losing hair with my configuration of Virtualmin, which started well.

What I’m trying to do:

  • I used to manage a few websites for myself and friends, without virtualmin, everything in /var/www
  • A friend got a wordpress developper to redo her website and would need access to the server. I took that opportunity to move to Virtualmin so as to have a clean and manageable website management system on my VPS. I’d use VirtualMin only to manage Apache virtualhosts, having emails and DNS outside (Cloudflare).
  • I would like to grant access to the WP dev to files and shell of one and only one domain, without them being able to view other files on my server. For this, I created a new domain,, inside Virtualmin, with a webmin user of the same name (domain dot com) and a mysql user (domain_com). I uploaded the zipped WP site inside public_html, and the WP dev needs to be able to unzip it, run a PHP script, and to test the website.

What I’ve tried:

  • Created a user in Virtualmin > Edit Users > Add a user to this server. It doesn’t help because that new user doesn’t come with a Webmin account, nor with a mysql account. What’s the intended purpose of users created there?
  • Created a user via Virtualmin > Administration Options > Manage Extra Admins > Add new Admin. Here again, the new user created doesn’t have any access. Is it correct to go to Webmin > Webmin Users to edit them, despite the disclaimer “This Webmin user should not be edited as it is managed by the Virtualmin Virtual Servers module. Click here to bypass this warning and edit the user anyway - but beware that any manual changes may be over-written!”? I found nowhere in Virtualmin a way to grant specific rights (here, Shell).
  • Therefore, I edited that user privileges in Webmin > Webmin Users > extraadmin > Available Webmin Modules > Command Shell config page (https://myvps:10000/acl/edit_acl.cgi?mod=shell&user=extraadmin), and enabled “Execute commands as user” instead of the default, root, and set “Permissions for all modules” to chroot them to /home/ How okay is it to have a user of a virtual domain being by default able to run as root? I’m worried that default settings can get restored at some point.
  • With these steps, extraadmin can log in webmin, has to know the domain_com mySQL password, and despite being apparently chrooted in /home/ in the Virtualmin shell, that user can navigate and list files on the whole server.

I eventually gave up and removed permission to “Command Shell” before giving that extra admin user credentials to the WP dev. He cannot proceed because he needs to set up the website, when doing “Preview Website” in Virtualmin he either gets a Cloudflare 520 error or a " Warning! Webmin has detected that the program …" error.

So here I am. I feel it’s not right to have to tweak security access controls buried down Webmin menus, and there must be a more secure and easier way to achieve my goal. What do you think?

|OS type and version:| REQUIRED |
||| Ubuntu 18.04 LAMP with Webmin 1.984 and Virtualmin 6.17.gpl-3

hi, its easy, what access you need to give them to manage the website and files or root?

Edit: ftp is ill advised - its insecure and plain text. ssh… you are fine, just tell me what you need to give them access to? just files or root (system admin)…I will navigate you.


Ideally, when the virtual server owner logs into Webmin with their credentials, they have shell access under the user by clicking on the shell button at the bottom left of their Webmin panel, and are chrooted in /home/, meaning they can view and edit their own files in /home/ like /home/, but they can’t list files and directories in /home/

Currently, from the Webmin admin login > Webmin > Webmin users >, I can see that user has the following attributes:

  • password set to ‘Unix authentication’
  • Storage type: Local files
  • Privilege level: Unrestricted
  • Available Webmin Modules (among othres): Command Shell, and inside that submenu, Execute commands as user, Chroot to directory ‘/home/chroot/164307859387143’

From the Webmin admin login > Webmin > System > Users and groups >, I see that Home Directory and Shell for user are set to ‘/home/chroot/164307859387143/./home/’ and ‘/usr/sbin/jk_chrootsh’

Out of curiosity, why is ftp ill advised? I thought vsftpd with the user chrooted in /home/ wouldn’t be especially less secure than anything else.

Generate ssh keys with passphrase.

Then you can if you want even disable ftp server.
FTP is very old and known insecure, to easy to lose credintials because of weak clients mostly.

Also take care of MYSQL other paswords and if possible even user, and is even better to have diferent passwords per database.
If needed you can create for mysql related a kind of DBadmin with more rights

1 Like

@jb1 i strongly agree with @jotst regards databases I would just create just user which could have access and rights for database to manage it, once work done delete ssh key and change password for that user in phpmyadmin and youre done. Of course in php scripts or whatever is accessing that db you would just update that password to and youre done.

Hey, thanks both. These are solutions outside virtualmin, I thought I could use Virtualmin or Webmin to manage users. I would also expect things to start breaking (or introduce vulnerabilities) if I manage user access rights with and without virtualmin/webmin at the same time. I’ll follow your advice if I can’t find a managed option.

I suspect my issue is linked to using jailkit, as I noticed I cannot log in a virtualmin-created user with sudo su - from my terminal, the authentication succeeds but then pam says “Cannot create session: Already running in a session” and jk_chrootsh throws an error in auth.log.

When you create a new domain, you also create a new user and virtualmin setups up a /home/username/. This should create a user that has access to only /home/username. I would install WP through VM and then import the database as it will keep permissions clean.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.