Quelle est la différence entre / sbin / nologin et / bin / false?
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 un shell de /sbin/nologin au lieu.
Je vois sur la page de manuel que /sbin/nologin imprime un message à l'utilisateur disant que le compte est désactivé, puis quitte. Vraisemblablement /bin/false n'imprimerait rien.
Je vois aussi que /sbin/nologin est répertorié dans /etc/shells, tandis que /bin/false n'est pas.
La page de manuel indique que FTP désactivera l'accès pour les utilisateurs avec un Shell pas répertorié dans /etc/shells et implique que d'autres programmes peuvent faire de même. Est-ce que cela signifie que quelqu'un pourrait FTP avec un compte qui a /sbin/nologin comme coquille?
Quelle est la différence ici? Lequel de ces éléments dois-je utiliser pour désactiver un compte d'utilisateur et dans quelles circonstances? Quels autres effets une liste dans /etc/shells avoir?
/bin/false est un programme utilitaire, compagnon de /bin/true, ce qui est utile dans un certain sens abstrait pour s'assurer qu'Unix est complet. Cependant, des objectifs émergents pour ces programmes ont été trouvés; considérez l'instruction BASH /some/program || /bin/true, qui sera toujours booléen-évalué à true ($? = 0) peu importe le retour de /some/program.
Une utilisation émergente de /bin/false, comme vous l'avez identifié, est un shell nul pour les utilisateurs non autorisés à se connecter. Dans ce cas, le système se comportera exactement comme si le shell ne fonctionnait pas.
POSIX (bien que je puisse me tromper et que cela puisse être le SUS) contraint ces deux commandes à ne rien faire d'autre que renvoyer la valeur booléenne appropriée.
/sbin/nologin est un utilitaire BSD qui a un comportement similaire à /bin/false (renvoie booléen false), mais imprime également la sortie, comme /bin/false est interdit de faire. Ceci est censé aider l'utilisateur à comprendre ce qui s'est passé, bien que dans la pratique, de nombreux émulateurs de terminaux se ferment simplement lorsque le shell se termine, ce qui rend le message presque illisible de toute façon dans certains cas.
L'inscription de /sbin/nologin dans /etc/shells. L'effet standard de /etc/shells consiste à répertorier les programmes pouvant être utilisés avec chsh lorsque les utilisateurs changent leur propre shell (et il n'y a aucune raison crédible de changer votre propre shell en /sbin/nologin). Le superutilisateur peut changer le Shell de n'importe qui en n'importe quoi. Cependant, vous souhaiterez peut-être répertorier les deux /sbin/nologin et /bin/false dans /etc/rsh, ce qui interdira aux utilisateurs avec ces shells de changer leur Shell en utilisant chsh dans le cas malheureux qu'ils obtiennent un Shell.
Les démons FTP peuvent interdire l'accès aux utilisateurs dont le shell n'est pas dans/etc/shells, ou ils peuvent utiliser toute autre logique qu'ils souhaitent. L'exécution de FTP est à éviter dans tous les cas car sftp (qui fournit des fonctionnalités similaires) est similaire mais sécurisé. Certains sites utilisent /sbin/nologin pour désactiver l'accès Shell tout en autorisant l'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 cronjobs.
Dans les deux cas, scp ne fonctionnera pas avec un shell non valide. scponly peut être utilisé comme Shell dans cette instance.
En outre, le choix de Shell affecte le fonctionnement de su - (ALIAS su -l). En particulier, la sortie de /sbin/nologin sera imprimé sur stdout s'il s'agit du Shell; cela ne peut pas être le cas avec /bin/false. Dans les deux cas, les commandes s'exécutent avec su -cl échouera.
Enfin, la réponse:
Pour désactiver un compte, ne dépendez d'aucun de ces éléments, mais définissez le shell sur /sbin/nologin à titre informatif (sauf si /sbin/nologin est dans /etc/shells, à quel moment vous devez utiliser /bin/false, qui ne devrait pas l'être). Au lieu de cela, définissez le champ de mot de passe dans /etc/passwd à !, qui est garanti par crypt pour être valide sans mot de passe. Pensez à définir le hachage dans /etc/shadow de la même manière pour éviter les bugs. passwd -l le fera pour vous.
Une troisième façon 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 que le service qu'ils utilisent ne nécessite pas de Shell.
Après avoir fait des 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 au Shell, un message s'affichera à l'effet de This account is currently unavailable. Notez que vous pouvez changer cela en créant le fichier /etc/nologin.txt au moins sur les dérivés RHEL.
Comme vous le savez /bin/false n'est pas un Shell. Leur façon de fonctionner est qu'elle renvoie false qui se déconnecte immédiatement après la sortie du binaire. Notez que /bin/true aurait le même effet.
En ce qui concerne votre question FTP: Oui, vous avez raison de dire que le shell est défini sur /sbin/nologin permettra aux utilisateurs de se connecter au FTP pendant que /bin/false ou /bin/true empêchera complètement l'utilisateur de se connecter au service any.
Par conséquent, /bin/false ou /bin/true est préférable d'empêcher un utilisateur de se connecter à n'importe quel service, tandis que /sbin/nologin permettra toujours aux utilisateurs de se connecter à des services autres que SSH ou la console locale tout en signalant à l'utilisateur que le compte est inactif et qu'il est préférable de l'utiliser lorsque seule SSH/la console locale doit être verrouillée.
Quelqu'un a-t-il essayé pour prouver que/bin/false interdirait l'accès FTP?
Je viens de changer le Shell de mon utilisateur en/bin/false et j'ai pu très bien FTP.
J'utilise/dev/null pour complètement verrouiller l'utilisateur (enfin, sauf le courrier électronique, ils peuvent toujours POP3).