/bin/false is not security
semicomplete.com
semicomplete.com
If you have a larger number, assign them to a group and AllowGroup.
Simple, fast, and effective.
If you can turn off password auth in favor of keys, do that, too.
Use Kerberos and a Directory Service if you can, unless you have a solution to SSH key changes.
Sign your keys with a CA, and encode the "principals" that the user has (so, be able to log into some machines as themself, some machines as some other user), and a validity period. Revocation wasn't there yet when last I looked at it (mid-last-year), but might be there now.
One benefit is that individual connections don't need to be brokered by an external authentication/authorisation service. However, it is a relatively new feature and there may be rough edges (such as making sure all your clients have a recent enough version of the tools to work with certificates - Lion was the first MacOS X version to have it, for example).
But even if you use a static linked /bin/false you must make sure that you disable PermitUserEnvironment as sh(1) is executed if ~/.ssh/rc exists and sh is typically dynamically linked
At the time, I recall finding lots of misleading information on the Internet about restricting ssh, mostly task-oriented "howtos" that overlook the basic principles of operation in order to "get started quickly!"
In my experience, beyond "whitelisting" ssh access in the first place with AllowGroup and related, one should rely more on "deep" kernel-level restriction mechanisms (chroot, BSD jails, sandboxing, etc.) than "shallow" authorization controls ostensibly provided by ssh and/or the login subsystem.
(It seems one of the reasons you might want to allow someone an ssh account without a shell would be to give them a proxy with an internal IP address – a feature not a bug. Alternatively, it's possible every user casually ssh-enabled on these machines already had equivalent port-forwarding and shell capabilities on some other 'inside' machines, so this 'insecurity' is trivial.)
It wouldn't surprise me if this server was involved with the school's student information system and did just that.
Isn't this a greater problem than port forwards? Eg you could say ssh example.com sh to get a shell even if your login shell is set to /bin/false?
ssh example.com sh would just execute "/bin/false sh", or something like that, on the distant machine.
~/.ssh/rc
Commands in this file are executed by ssh when the user logs in,
just before the user's shell (or command) is started. See the
sshd(8) manual page for more information.
I don't think it would work directly through scp. From what I can tell from skimming the source, it is really just a wrapper over ssh. Meaning: it forks an ssh, with the commands 'scp -t/-f' on the distant side, and does its magic to connect the pipes where they should go. 'scp -v' gives the exact command, but I don't think it works without previously having a shell.
But, if you have access to the filesystem through other means, you could use the .ssh/rc trick to bypass /bin/false, and get ssh access.
To be more precise sh -c /bin/false -c '/bin/sh .ssh/rc' is executed where /bin/false is your shell as ssh uses popen(3) to run the command /bin/false -c '/bin/sh .ssh/rc'. I tested several shells which may be used as sh and none seems to read a user configurable file.
If you use a static linked shell and enabled PermitUserEnvironment an attacker can still use LD_* variables to circumvent restrictions as /bin/sh is typically dynamically linked.
/bin/false was set for the shell, BUT
feel free to use XDMCP.
/bin/false has never been security. It's just good behavior for users that aren't supposed to get a shell. And that's that, they dont get a shell. They get everything else. Generally, those are daemons !