how to enable ssh access just for the user folder

Hi There,

Today, when my customers access their webspace via ssh,
they can run the command "cd /home" and see all the other
users/customers that I have in my server.

How can I deny this access ?
I mean… he can access his webspace via ssh,
but he cannot go to /home or / or any other folder
(except his own)

Thank you,

This requires ssh to run in a chroot environment. We don’t recommend it, as it removes several security features from ssh.

Just make sure you’ve got your permissions set right on homes (750, this is configurable in Virtualmin), and nobody will be able to see anything sensitive, even if the users aren’t as careful with permissions in their home directory as they should be.

(msg duplicated)<br><br>Post edited by: Renato, at: 2007/09/19 15:51

Your question answered here:[faqs].html

Hi There,

Thank you for your reply.

But unfortunately, I am feeling very exclusive here!

All my home sub folders are "chmoded" to 750,
but every customer with ssh access can "see" all
the other users by running the command ls /home

Yes, that’s true. I just don’t see that it’s a problem.

You can, of course, make your users use FTP and put ProFTPd into chroot mode (I don’t recommend it, because FTP isn’t a very nice protocol or a very secure protocol, though it can be made better with the use of FTP with SSL).

Or, you could break several security mechanisms in SSH and run it into a chroot (I don’t recommend this either).

Those are the choices. I’m not going to pretend like those aren’t the choices, or that I don’t have an opinion on what is more secure. :wink:

Hi Joe,

Thank you for your reply.

I have around 40 websites / customers to be hosted in my new server,
and just 2 or 3 of them really need to use their webspace via ssh

Before I was using CPanel and every thing was ok,
but now, it will be pretty bad…


Before I was using CPanel and every thing was ok, but now, it will be pretty bad...

Ah, then why not use cPanel again? :wink:

I’m not going to stop you from doing something that I don’t think is a good idea–but I’m also not going to pretend to be enthusiastic about it just because cPanel does it.

I have been a customer of about 5-6 web hosting companies and I have not yet seen one from which I couldn’t find out other clients on the same machine. Even if you chroot ssh and ftp, there is still php and cgi. I don’t think you can chroot them all in a linux machine.

Even if a client cant list /home there are still all conf files of all almost all programs that list the logins, domains or virtual servers. You would have to protect them all (httpd.conf, awstats, webalizer…). Some hosting companies have a warning in the login screen that tells that they are recording every activity made in the shell. Maybe that would a partial solution for you also. And also to put a warning not to go beyond the own home directory.

When I first start using a new web hosting firm, I sometimes have looked the other domains the machine is hosting. If I am the only one, I might get worried :slight_smile:

So the questions is not, how you can block your customers from seeing other virtual servers, but how hard you want to do it for them. I personally don’t think domain names are sensitive information. User data, logs and passwords are. Just make sure your initial passwords are not domain names.

Hi Matti,

You brought up a very good point!

I was so blind just trying to hide my customers folders
from one another that I didn’t think about that.

Every customer with ssh access can access /etc
/usr etc…
and there are so many more pressing issues at hand!


Thank you very much for your enlightenment !

Every customer with ssh access can access /etc /usr etc... and there are so many more pressing issues at hand!


Thank you very much for your enlightenment !

Hehehe…You’ve gotten the wrong point from matti’s post, Renato!

He was telling you that your concerns are misplaced–these are not the security issues you believe them to be. UNIX permissions have been serving us well on multi-user systems for over 30 years. As long as you, as the root user, don’t do something stupid with sensitive data, it’s perfectly safe for your users to be able to look around the filesystem.

Everything that is sensitive, like passwords, for example, are encrypted and unreadable by normal users in the /etc/shadow file.

The other point matti was making was that even if you chroot your ssh users (removing privilege separation features from ssh, among other security features), they can STILL see anything on the system as long as they can run scripts via the web server. This is as true on cPanel as it is on any other system running a web server with script execution. Just think it through–Apache runs scripts as the user. There are dozens of “shell in a browser” scripts out there…install any one of them, and you have “access” to everything, just like you do via ssh. We must rely on UNIX security to protect those files from malicious intent (cPanel also must rely on UNIX security for this–just because an ssh login can’t see it, if the account allows arbitrary scripts to be installed, this capability exists).

So the two points matti was making are:

cPanel is giving you an illusion of security by chrooting your ssh logins. It is merely an illusion. The real security comes from a combination of UNIX permissions, OpenSSH having a good security history, privilege separation in OpenSSH (which chrooting it removes from the equation, taking away one of the real security features and replacing it with an illusory one), and SuExec in the webserver.

cPanel does not prevent your users from seeing those files any more than Virtualmin does. It just chroots ssh. The user still has everything they need to see those files, if they can run scripts via the web server (and if the user needs and warrants having ssh, he’s definitely a user that is demanding arbitrary script installation and execution).

In short, don’t panic. We’ve been letting untrusted users poke around in /usr and /etc for over 30 years, and the world has not ended. This is the UNIX security model. Don’t fight it. Everything will be fine.

Actually, there is one CP that prevents this, at both the script, FTP and SSH levels. That’s Ensim. It’s a pretty secure chroot, nothing’s unbreakable, but I haven’t seen a publically available exploit that breaks through it as yet.

That said, Joe is right that it’s secure, as long as the permissons are set right (ignoring information leakage <g>).

Actually, having gotten tired of hackers hammering SSH we just shut it off. The webmin command line works quite well and there’s nothing I want a client doing that can’t be done at the command line level. THis can be turned on for the domain admins quite simply, but yes, they can still CD and LS to their hearts content.


Actually, there is one CP that prevents this, at both the script, FTP and SSH levels. That's Ensim.

Do they run a separate Apache instance for every virtual server? (There’s no other way to make scripts run in a chroot. This would require an IP per virtual server.)

Also worth noting is that even mail delivery can trigger scripts, if any sort of custom delivery option is offered–.forward, procmail, etc. can all trigger script runs which would be outside of the chroot. So, it’s a huge endeavor to chroot everything.

Our feeling on that is that once you have a complete chroot–with apache, mail, and all–you might as well run a vserver, which offers complete isolation and "root" level access for the customer. This is, of course, a valid desire–for serious ecommerce and such, you really need full control of the stack. Which is why we now have products in that space (VM2 is in private beta, and should be launched publicly in a couple of weeks, once the obviously stupid bugs are worked out).

While I don’t know all of the details, it’s done with suexec and chroot for the most part. PHP for example running as a CGI script as the domain user rather than as the web server user. Ensim’s future is “interesting” to say the least, given as it’s just been bought by SWSoft (in their Microsoft week <g>), so I’m not pushing it as preferred over Virtualmin, just saying that more separation is possible. SSH is chrooted, PHP & CGI scripts are run as the domain user rather than web server user (and chrooted).

(Just for info - It’s not easily achieved, each site has it’s own environment built up of hard links, kind of a quasi-VPS. It’s a nice, if complex, system)

Yeah, SWWSoft has been doing a lot of buying lately. They bought up PSoft (which was an early Virtualmin version licensee with their CP+ product, though they hadn’t updated it in ages) a few weeks ago, too.

I’m still having trouble imagining how Apache could be restricted to a chroot without running a new one for every account.

But, regardless, we’ve got VM2 coming out in the next week or so, and it provides real isolation for folks that need it–root level accounts via vservers, Xen, Solaris Zones, or EC2. It’s nifty, and doesn’t do crazy chroot hackery (it instead does crazy virtualization hackery). :wink:

Will there be a VPS license pricing structure? That is, discounted for multiple per server, or even a per server (hardware) license for Virtualmin?

A late poster on this topic… but MY reason for wanting to isolate my customers from seeing other web directories is simply… the competition. I web host for two competing companies, If they FTP and see that their competitors host with me too… they might just take their business elsewhere… :frowning:


If a user is allowed to upload code to your server (such as PHP code for a website), there’s not much you can do to prevent them from being capable of getting a list of usernames on your server.

If that’s going to be an issue, I’d recommend putting your users each on a private VPS rather than a shared hosting server.

If you just want to prevent an FTP user from accidentally running into the usernames, you can go into Limits and Validation -> FTP Directory Restrictions, and setup a FTP Directory Restriction that locks a user within their home directory. That will prevent them from wandering around the server with their FTP client.

However, since the /home directory is world readable, they could use PHP (or any form of CGI script) to obtain those names elsewhere.


I agree with Eric there. Shared hosting means just that: hosted websites can, to a certain extent, see what other sites exist. That depends on what rights you give the customers. To be certain that they cannot see what others are hosting, you must forbid them SSH login, restrict FTP to their home directory, and disallow upload of PHP code (or any other executable code).

In addition to that, there’s a very easy - and inevitable - way to determine that you’re hosting the competition: DNS name resolution.

If resolves to the same IP address as, it’s clear that you’re hosting them both. They don’t need any FTP or other access to find that out, and there’s nothing you can do to prevent that.

Even if you put them on separate VPSes, and even if you get separate IP networks for them, there’s still evidence that you’re hosting them both, in the form of RIPE/ARIN database entries (revealing you as responsible for both networks).

In short, if you decide to host a company and their competition, you must be aware that there are always ways to find out that you’re doing that. So, be honest with them in the first place, and if they don’t want to be hosted “side-by-side” with the competition, they need to go elsewhere.