Since I've had an overlarge caffeine shot by now I'll allow myself a bit of a lengthy reply :-]
There are 3 basic ways to guard against users snooping.
Chroot, restricted shell and ACL's.
Since you're letting 'em in tru OpenSSH, there's 4th way: a chroot patch out for openSSH-3.4 (untried).
By putting a user in a "chrooted" jail, what they see as home will be changed to "/". Pro is you don't have to worry about the user seeing the system, con is because the user root now is "/" you will have to provide all system configs, libs and binaries necessary for the usual tasks. This isn't a real PITA since you can use a static shell like ash, and the busybox binary, and populate their environment using some form of automation (I use "jail", then tweak it manually). Another bad thing is providing access to /proc, devices like /dev/kmem and setuid binaries within the chroot which can be used to "tweak" the kernel (Silvio Cesare) or break out of a chroot.
You can opt to not mount /proc for users, which means they can't use proc-utils like ps, top and such, or using the Grsecurity kernel patch, you can mount /proc but restrict what they see to their own processes. The patch also covers tricks like writing to kmem, automagically provides "chdir" before chroot, allows for logging all commands in a chroot.
*It also allows for user/process ACL's and TPE. TPE stands for Trusted Path Execution which means if you opt to *not* chroot users, they will *only* be able to run binaries in the approved system dirs and *not* from their home!
Mart hinted at using rbash, under which you can make symlinks to binaries outside the users home so you don't have to include binaries etc which is efficient, which is also bad, because if you include /bin they'll be able to exec bash or chsh and so break out of the rbash. Another other side effect of rbash seems that this user won't be able to execute binaries in subdirs of his/her own home (IIRC).
There are a few tools that can help you put up Access Control Lists. There's ACL/Linux Trustees ACL, RSBAC, Grsecurity (sure I'm forgetting some).
A stupid example using the Grsecurity kernel patch could be:
Which means a process for instance can enter (execute) /bin, but can't read it's contents. This is a stupid "security by obscurity" example because if you know the name of the binary you'll still be able to execute it. OTOH note /some/dir, it is hidden completely...
Finally since you're on a PAM-aware system you can provide some restrictions (tho they won't guard from snooping) right now by restricing who logs in from where (/etc/usertty, hosts.(allow|deny) and /etc/security/*), shell based limits (ulimit, /etc/security/limits.conf) and who has access to system services (allow lists, /etc/pam.d). Also if your system is stable you could chattr +i your system configs to guard against changes, but you'd have to know which ones.
And please read up on "chroot" rbash and ACL's.