2023-09-17
Unix shells are generally not viable access control mechanisms any more
Once upon a time, if you had a collection of Unix systems, you could reasonably do a certain amount of access control to your overall environment by forcing logins to have specific administrative shells. As a bonus, these administrative shells could print helpful messages about why the particular login wasn't being allowed to use your system. This is a quite attractive bundle of features, but unfortunately this no longer works in a (modern) Unix environment with logins (such as we have). There are two core problems.
First, you almost certainly operate a variety of services that normally only use Unix logins as a source of (password) authentication and perhaps a UID to operate as, and ignore the login's shell. This is the common pattern of Samba, IMAP servers, Apache HTTP Basic Authentication, and so on. In some cases you may be able to teach these services to look at the login's shell and do special things, but some of them are sealed black boxes and even the ones that can be changed require you to go out of your way. If you forget one, it fails open (allowing access to people with an administrative shell that should lock them out).
(One of these services is SSH itself, since you can generally initiate SSH sessions and ask for port forwarding or other features that don't cause SSH to run the login shell.)
Second, you may operate general authentication services, such as LDAP or a Single Sign On system, and if you do these authentication services are generally blind to what they're being used for and thus to whether or not a login with a special shell should be allowed to pass this particular authentication. The only real solution is to have multiple versions of these authentication systems with different logins in them, and point systems at different ones based on exactly who should be allowed to use them.
A similar issue happens with Apache HTTP Basic Authentication in common configurations, where you have a single authentication realm with a single Apache htpasswd file that covers an assortment of different services. If you need certain logins ('locked' logins or the like) to be excluded from some of these services but not others, either you need multiple htpasswd files (at least) or you need to teach each such service to do additional checks.
(In general you're going to have to try to carefully review who should be able to use which of your services when, and the resulting matrix is often surprisingly complicated and tangled. Life gets more complicated if you're using administrative shells for reasons other than just locking people out with a message, for example to try to force an initial password change.)
Today, the only two measures of login access control that really work in a general environment are either scrambling the login's password (and disable any SSH authorized keys) or excluding the login entirely from your various authentication data sources (your LDAP servers, your Apache htpasswd files, and so on). It's a pity that changing people's shells is no longer enough (it was both easy and convenient), but that's how the environment has evolved.