How to restrict shell access?

I've used https://www.adg.us/computers/chrsh.html for this, but with a very limited number of users that I'm sure I could've trusted with a normal shell.

I don't think that rssh is experimental. In fact, I'm pretty sure that the IT people where I work used it (they wanted a way for people to upload files without running computational simulations on the web server). As for keeping people out of others' directories, that's what chmod is for ---remove read, write, and execute priviledges for everyone but the user you want to have it (without execute priveleges for a directory, users can't even enter it). If only user bob has acess to /home/bob then he's safe.

What you want is a chroot jail. Basically, the user's shell 'thinks' that it's / (root directory) is whatever you set it to, say /home/user. Short of possible security flaws, they can't get out of it. (The downside is that you have to copy over whatever commands you want them to be able to use... This does, however, let you control exactly what they can use.) It doesn't sound like you want them having shell access at all. I use WinSCP for file uploads from Windows to my Linux server. In theory, you could set their login shell to something like /bin/false, and they won't be able to get a shell. (However, I find that chmod is a pretty useful tool!) Any scp/ssh/sftp stuff encryptes password transmission.

http://www.debian-administration.org/articles/94

Also, note that if you're a "complete Linux n00b," I'm concerned that you're maintaining a Linux server with 100 users on it. It does take a bit of getting used to. I found that cPanel (non-free) is a pretty easy-to-use 'control panel' for a web-hosting setup, and if you set people's shells to 'jailshell,' it basically set up the chroot jail for them. I seem to be getting a great deal of opinions without the reasoning behind it Welcome to the world of Linux.

Oh, and if you want to allow SSH for some users (the ones you want to trust to run mysql, etc) but not others, http://aplawrence.com/SCOFAQ/FAQ_scotec4sshdusers.html%20

I do this using chrooted SSH. There are pre-patched openssh-chroot tarballs http://chrootssh.sourceforge.net/download/ - you will probably need to upgrade openssh and zlib as well. Then, you can chroot each user into their own jail, or make one jail for each group that has only the binaries they should be able to use. Then you can move the directories they should be able to access into their jail and symlink them from their "real" locations (you can't do it the other way around!). Building the jail isn't easy though - you have to statically build all the binaries, or strace all the library calls. I have step-by-step instructions and a pre-built jail listing for RedHat - e-mail me if you want to try this and I can save you a lot of time.

Check out scponly: http://www.sublimation.org/scponly/

I'm afraid that you may have a few misconceptions about what is really possible. It is exceedingly hard to TRULY isolate users on a shared hosting setup. Let me explain. You are attacking this from the angle of the shell that the user is allowed to use. This works to keep beginners and average users from doing bad things, but it won't do squat against a determined attacker. For example, if you allow your users to run PHP scripts then they basically have full access to the entire filesystem through PHP. In fact there are "php shell" scripts that essentially give you a full shell in the context of the Apache user (e.g. www-data, httpd, nobody, etc.) entirely through a web interface, so the shell setting you have for them in /etc/passwd is completely irrelevant. There is safe mode for PHP, but the PHP documentation is very clear that this is not a security catch-all, that safe mode should not be relied upon to secure a machine as there are always ways to get around it. (And some scripts fail with safe mode enabled, so in a hosting environment you can't always enable it.) But even if you don't allow your users to have PHP scripts, there are still tons of ways to get around the shell restriction. For example, with cPanel the default was to assign users a restricted shell, but you could just create a crontab entry to run chsh and change your shell back to bash. So much for that idea. And if you allow your users to run CGI scripts like perl, then right there they have complete access to the entire system (in the security context of the apache user) regardless of what shell you may have given them. The realization that I am trying to get you to make here is that unless you allow your users 100% static pages and no scripting, they will have complete access to the system in the context of whatever user Apache runs as -- access files, run commands, etc. This is the definition of scripting, after all. So farting around with restricted shells doesn't change this fact at all. Hell even without PHP and with only CGI a determined user could compile their own shell with a reverse-connect-back socket, upload it to their cgi-bin directory, hit that URL, and bam, they have a full shell in the context of the Apache user. The only true way to rope them off is to ensure that all scripts run in the context of the user, and not the apache daemon. This can be done, I believe, with a combination of suPHP and FastCGI. But there could be a major performance hit to doing it this way, and there still might be holes. I recommend that instead of trying to pretend that the security model is something it's not, you embrace it and live with it.