When asked about security on a multi-user Linux system, a wise man once said "everyone is root if you allow them to login as a user." There is plenty of truth in that, but embracing imminent compromise isn't always acceptable. Let's take a look at how you can limit your exposure while letting unknown and untrusted users login with a shell.

There are two groups of people who typically want to heavily restrict login users. First, the collaborators: possibly two separate organizations that have been forced to work together. Second, people who wish to allow some shady characters access to a shell but believe they may attempt to compromise security. If at all possible, the best policy is to simply not give access out, and if you do, make sure patches are applied daily.

To say that you simply shouldn't give out shells to untrustworthy users may work in a few instances, but sometimes you have to let users in. Take a fairly simple example where remote users at another site need to log in and run the same series of commands every day. Assuming their task can be easily scripted, and if it's their only purpose on the server, a shell certainly isn't necessary. OpenSSH allows a set of restrictions to be applied to an SSH key.

At the end of an SSH key entry, you can tack on these options:

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="~/bin/script.sh"

This effectively restricts any SSH connections using this key to only being allowed to run the referenced script. This can even be a setuid script that restarts a Web server, for example. It's quite safe, because OpenSSH will reject any variation of the command= text. Users possessing this key will only be able to execute the command that is explicitly allowed.

Aside from that, and possibly some fancy Web-based tools or cron jobs, there aren't may options left. At times users just need to be able to login and work, and in those cases you have your work cut out for you.