Users don't “effectively have root access” just because they can browse other directories. All users with shell access can browse the software installation — this isn't confidential information after all, since it can be downloaded from any number of sites. If there are directories that you don't want to expose to all shell users, given them appropriately restrictive permissions.
If you want to have a second layer of safety, you can make the accounts more restricted. If you only want to allow these users to browse, upload and download files under
/var/www/html/testuser.com, then don't give them a shell account, give them a restricted account that can only use SFTP. You can specify options for a specific account in
sshd_config with a
Match block. (Put this at the end of the file, since the
Match directive extends to the next
Match directive or to the end of the file.)
Match User testuser
If you want to allow the users to use a few more commands such as scp and rsync, but not general shell access, use rssh or scponly as the shell on their account, and install and configure rssh or scponly to specify which commands you want to allow (see Do you need a shell for SCP?).
If you want to give a shell account that only allows running a few whitelisted programs, make their shell a restricted shell. Note that these users will be able to access files outside their home directory, based on file permissions.
If you want to give full shell access, but make everything other than home directories invisible, then you need to create some form of jail. The weakest form of jail is a chroot jail, which restricts the user to a branch of the directory tree. Restricting a user to a chroot is as easy of specifying
sshd_config; however, since the user cannot exit the jail, the directory must contain all the programs that the user will use and their data. You can use bind mounts to make some directories (e.g.
/usr) visible inside the jail.