Niet alle gebruikers hebben een shell nodig. Voor gebruikers met speciale (of zelfs geen) eisen loont het daarom de moeite om een speciaal programma als shell in te stellen. Systeemaccounts die niet mogen inloggen, krijgen bijvoorbeeld vaak als shell /bin/false. Voor gebruikersaccounts die niet mogen inloggen (lokaal of via ssh) kun je perfect hetzelfde instellen, bijvoorbeeld als het om gebruikers gaat die de server alleen als mailserver gebruiken via POP of IMAP vanuit hun lokale e-mailclient. De shell /usr/sbin/nologin is daarvoor overigens iets gebruiksvriendelijker: die geeft de melding "This account is currently not available." in plaats van botweg de verbinding te verbreken.

Creatiever

Maar niets houdt je tegen om wat creatiever te zijn. In het geval van de e-mailgebruikers bijvoorbeeld: waarom stel je niet /usr/bin/passwd als hun shell in? Dan kunnen ze op elk moment op een veilige manier via ssh het wachtwoord van hun mailbox aanpassen, maar ze kunnen niet inloggen om andere zaken uit te voeren. Ze hoeven dan de supportmensen niet lastig te vallen als ze hun wachtwoord willen wijzigen. Uiteraard kun je ook een voor je situatie op maat gemaakt shellscript als shell opgeven.

Gebruik je een speciale shell, houd er dan wel rekening mee dat een aantal ftp-servers geen toegang verleent aan gebruikers waarvan de shell niet in het bestand /etc/shells vermeld staat. Wil je hen wel ftp-toegang geven, voeg de shell dan toe aan dit bestand. En tot slot: de shell instellen voor een programma dat de gebruiker niet toelaat om in te loggen is, niet altijd een adequate beveiliging. De gebruiker kan bijvoorbeeld nog altijd met ssh aan port forwarding doen, of andere taken die geen shell openen.

Bron: Techworld