Quelle est la différence entre / sbin / nologin et / bin / false?

69

J'ai souvent entendu dire qu'il était recommandé de désactiver un compte d'utilisateur en définissant son shell sur /bin/false. Mais, sur mes systèmes Linux existants, je constate qu’un grand nombre de comptes existants (tous des comptes de service) ont à la place un shell /sbin/nologin.

La page de manuel /sbin/nologinaffiche un message indiquant à l'utilisateur que le compte est désactivé, puis se ferme. Vraisemblablement /bin/falsen'imprimerais rien.

Je vois aussi que cela /sbin/nologinest répertorié dans /etc/shells, alors que /bin/falsenon.

La page de manuel indique que FTP désactivera l’accès des utilisateurs dont le shell n’est pas répertorié /etc/shellset implique que d’autres programmes peuvent faire de même. Est-ce que cela signifie que quelqu'un pourrait utiliser FTP avec un compte qui a /sbin/nologinpour shell?

Quelle est la différence ici? Lequel de ces devrais-je utiliser pour désactiver un compte d'utilisateur et dans quelles circonstances? Quels sont les autres effets d'une liste dans /etc/shells?

Michael Hampton
la source
1
Comme des informations générales qui fonctionnent. Je pense spécifiquement du point de vue de l'administration du système.
Michael Hampton
Juste comme un document d'information.
Demourati

Réponses:

70

/bin/falseest un programme utilitaire, associé à /bin/true, qui est utile dans un sens abstrait pour s'assurer que Unix est complet. Cependant, des objectifs émergents pour ces programmes ont été trouvés; considérons l'instruction BASH /some/program || /bin/true, qui sera toujours booléenne-évaluer comme vraie ( $? = 0), peu importe le retour de /some/program.

/bin/falseComme vous l'avez indiqué, une utilisation émergente correspond à un shell null pour les utilisateurs non autorisés à se connecter. Dans ce cas, le système se comportera exactement comme si l'exécution du shell avait échoué.

POSIX (bien que je puisse me tromper et qu'il se peut que le SUS) contraigne ces deux commandes à ne rien faire d’autre que de renvoyer la valeur booléenne appropriée.

/sbin/nologinest un utilitaire BSD qui a un comportement similaire à /bin/false(renvoie boolean false), mais affiche également la sortie, comme il /bin/falseest interdit de le faire. Ceci est supposé aider l'utilisateur à comprendre ce qui s'est passé, bien qu'en pratique, de nombreux émulateurs de terminal se ferment simplement lorsque le shell se termine, rendant le message presque illisible dans certains cas.

Il y a peu de but à la liste /sbin/nologinen /etc/shells. L’effet standard de /etc/shellsest de répertorier les programmes pouvant être utilisés chshlorsque les utilisateurs changent leur propre shell (et il n’existe aucune raison valable de changer votre propre shell en /sbin/nologin). Le superutilisateur peut changer la coquille de n'importe qui. Cependant, vous voudrez peut-être lister les deux /sbin/nologinet /bin/falsein /etc/rsh, ce qui empêchera les utilisateurs de ces shells de changer de shell en utilisant, chshdans le cas malheureux, l'obtention d'un shell.

Les démons FTP peuvent interdire l'accès aux utilisateurs dont le shell n'est pas dans / etc / shells, ou utiliser toute autre logique de leur choix. L'exécution de FTP est à éviter dans tous les cas car sftp(qui offre une fonctionnalité similaire) est similaire mais sécurisée. Certains sites utilisent /sbin/nologinpour désactiver l' accès au shell tout en permettant un accès sftp en le mettant dans /etc/shells. Cela peut ouvrir une porte dérobée si l'utilisateur est autorisé à créer des tâches cron.

Dans les deux cas, scpne fonctionnera pas avec un shell non valide. scponlypeut être utilisé comme un shell dans ce cas.

De plus, le choix du shell affecte le fonctionnement de su -(AKA su -l). En particulier, la sortie de /sbin/nologinsera imprimée sur stdout s'il s'agit de la coque; cela ne peut pas être le cas avec /bin/false. Dans les deux cas, les commandes exécutées avec su -clvont échouer.

Enfin, la réponse:

Pour désactiver un compte, ne dépendez d’aucun d’eux, mais définissez le shell sur /sbin/nologinà des fins d’information (à moins qu’il ne /sbin/nologinsoit entré /etc/shells, vous devez alors utiliser /bin/falsece qui ne devrait pas être le cas). Au lieu de cela, définissez le champ de mot de passe /etc/passwdpour !, qui est garanti par cryptêtre valable pour aucun mot de passe. Envisagez de définir le hachage de /etc/shadowla même manière pour éviter les bugs. passwd -lfera cela pour vous.

Un troisième moyen de désactiver un compte consiste à définir le champ de date d'expiration du compte sur une date ancienne (par exemple usermod --expiredate 1). Cela empêchera les connexions si votre configuration permet aux utilisateurs de s'authentifier auprès de leur compte unix sans mot de passe et si le service utilisé ne nécessite pas de shell.

Faucon Momot
la source
9
Bien que cette réponse résume parfaitement les différentes options (et répond à la question), je ressentais le besoin de pointer vers une ressource utile pour ce cas d'utilisation, qui est au moins disponible dans le stock des dépôts Debian, dans le titantoolspaquet: noshell. Ce pseudo-shell fournit des fonctionnalités d'audit. La journalisation sur syslog tente d'utiliser des comptes avec noshellson shell, tout en interdisant l'accès.
Dawud
1
Il n'est en aucun cas apocryphe, mais est en fait assez commun parmi les administrateurs système d'un certain millésime (toux), à utiliser /bin/falsecomme shell de connexion pour les personnes qui ne devraient pas se connecter.
MadHatter Le
2
Apocryphe en ce sens que ce n'est pas l'utilisation prévue à l'origine. Je n'ai pas dit anachronique; Je le vois tous les jours :)
Falcon Momot Le
1
Désactiver le compte avec un mot de passe invalide ne fonctionne pas trop bien avec ssh. Si l'utilisateur avait déjà configuré l'authentification par clé publique, il pourrait peut-être y accéder de toute façon.
Joshudson
3
sshd est documenté pour vérifier que les comptes verrouillés de certaines manières (les hachages de mot de passe commençant par! sont mentionnés spécifiquement) même avec pubkey auth.
Falcon Momot
13

Après avoir fait quelques recherches à ce sujet, la méthode que vous utilisez dépend de ce que vous devez verrouiller. Si un utilisateur se connecte avec cet ensemble sur le shell, un message s'affichera indiquant This account is currently unavailable.que vous pouvez le modifier en créant le fichier /etc/nologin.txtau moins sur les dérivés RHEL.

Comme vous le savez, ce /bin/falsen’est pas une coquille. Leur façon de fonctionner est qu’elle renvoie false qui se déconnecte immédiatement après la sortie du fichier binaire. Notez que cela /bin/trueproduirait le même effet.

En ce qui concerne votre question FTP: Oui, vous avez raison dans ce que la coquille ayant mis à /sbin/nologinpermettra aux utilisateurs de se connecter à FTP tout /bin/falseou /bin/trueempêche complètement l'utilisateur de se connecter à tout service.

Par conséquent, /bin/falseou /bin/trueest préférable d'empêcher un utilisateur de se connecter à un service, tout /sbin/nologinva encore permettre aux utilisateurs de se connecter à des services autres que SSH ou console locale tout en fournissant des informations à l'utilisateur que le compte est inactif et est le plus utilisé lorsque que SSH / local la console doit être verrouillée.

Jacob
la source
2

Euh, est-ce que quelqu'un a essayé de prouver que / bin / false interdirait l'accès FTP?

Je viens de changer le shell de mon utilisateur en / bin / false et je pouvais utiliser le protocole FTP.

Je / dev / null pour complètement verrouiller l'utilisateur (bien, sauf courrier électronique, ils peuvent encore POP3).

Jim Dunn
la source
Avez-vous eu dedans /etc/shells? Comment votre serveur FTP est-il configuré?
Michael Hampton
il n'y a pas de règle disant qu'un utilisateur a besoin d'un shell pour se connecter à un serveur FTP.
Petter H
Il sera interdit sur certains démons FTP et pas sur d'autres. Il y a beaucoup de différences dans la fonctionnalité entre les différentes. L'implémentation classique interdira l'accès à tous ceux qui n'ont pas de shell, mais cela ne signifie pas que toutes les implémentations doivent le faire.
Falcon Momot