Repeat after me: Running ANY permission command on / without knowing exactly what you're doing is a great way to break your system. Even if you know what you're doing, it's still probably the wrong thing to do.
In your case, the command won't work because it's the wrong one to start. Secondly, groups are a very valid Linux construct of users, and blocking off groups from accessing files is a really really bad idea.
If I'm understanding your case properly, you want to block users from resources that they aren't authorized to read. Fortunately for you, there are a few ways to do this, each with tradeoffs.
Option 1: No Shell At All (Best way)
You're using SSH to allow users to tunnel into a secure server, right? Why do users even need a shell in this case? Just block their access to the shell, and only let them tunnel!
To do this, simply create a new group called noaccess or similar. Then, copy and paste the below into your /etc/ssh/sshd_config file:
Match Group noaccess
AllowTcpForwarding yes
X11Forwarding no
If you want to be even more secure by restricting where they can tunnel, you can add the parameter PermitOpen to the SSH config. For example, if you want to only allow users to forward to port 1337 on the current server, you would add PermitOpen localhost:1337 to your config file, right under the AllowTcpForwarding directive, like so:
Match Group noaccess
AllowTcpForwarding yes
PermitOpen localhost:1337
X11Forwarding no
...
Finally, set the shell of the users to /bin/true by running the command chsh -s /bin/true <username>. Users will be silently (and forcefully) kicked back if they try to start any sort of interactive session. If you want to include a "friendly" error message, you can create a quick-n-dirty "fake" shell that will spit back an error message.
SSH gets rather annoyed when it can't access a shell, so you need to pass the command-line argument -N to the OpenSSH command, like so:
ssh user@example.com -N -L 3307:localhost:3306
If you're using PuTTY, make sure the highlighted checkbox is selected:
I've gone ahead and made a really simple (untested) shell that spits back an error message, and also keeps the terminal window open so that -N is unnecessary. You can find the source here if you want to compile and use it. Even with this, you should still use -N, but it's no longer absolutely necessary.
Option 2: Let them be
Users in Linux already have a pretty acceptable permission set. They can read files that are relevant to them and are important for the functionality of the system. At the same time, files that are "protected" (like private keys and
/etc/shadow) already disallow reads from unauthorized users.
If your users are trustworthy already (and are actually going to be working on your system), this is the best option -- at the cost of keeping users out of where they don't belong
Option 3: Selective Targeting
If Option 2 is still too insecure for your needs, you can chmod o-rwx files that you don't want them to access. Examples of these include "secure" config files. However, you must be very careful that you don't cause services and applications to lose access to files that are needed to do their job.
You could also use Access Control Lists to block groups of users off of files, without setting them as the owning group. I caution, however, that this is fairly involved, and it opens up a way to allow users to "escape" their confined set if they find a shelled user that isn't in the blocked group.
Option 4: chroot
Using chroot allows you to control exactly what your users have access to. You decide what permissions, what commands, and so on. This is a very involved method that needs a lot of work to get working right, so it's not recommended for everyone.
If you're interested, this question explains it rather well.
