GNU/Linux >> Tutoriels Linux >  >> Linux

Pourquoi l'utilisateur 'bin' a-t-il besoin d'un shell de connexion ?

Un utilisateur qui a un shell valide et aucun mot de passe peut toujours se connecter par des méthodes sans mot de passe, la plus courante étant une clé ssh. Un shell valide est nécessaire pour exécuter les tâches cron. Un shell valide est également nécessaire pour su bin -c 'wibble' pour fonctionner (sur Linux au moins, su bin -s /bin/sh -c 'wibble' fonctionnera également).

Dans le cas de bin , la plupart des systèmes n'exécutent jamais une commande en tant que bin en fonctionnement normal, donc en réglant le shell sur /bin/false ce serait bien.

Il n'y a aucun risque d'attaque directe permettant bin pour se connecter via SSH, car cela nécessiterait de créer /bin/.ssh/authorized_keys en tant qu'utilisateur bin ou en tant que racine. En d'autres termes, la seule façon d'entrer est d'être dedans. Cependant, avoir un shell valide augmente le risque de mauvaise configuration. Il peut également permettre certaines attaques à distance avec des services autres que SSH ; par exemple, un utilisateur signale qu'un attaquant pourrait définir un mot de passe pour daemon à distance via Samba, puis utilisez ce mot de passe pour vous connecter via SSH.

Vous pouvez boucher le trou SSH en listant les noms des utilisateurs du système dans un DenyUsers directive en /etc/ssh/sshd_config (malheureusement, vous ne pouvez pas utiliser une plage numérique). Ou, à l'inverse, vous pouvez mettre un AllowGroups et n'autoriser que les groupes contenant des utilisateurs physiques (par exemple, users si vous accordez à tous vos utilisateurs physiques cette appartenance au groupe).

Il y a des bogues signalés sur ce problème dans Debian (#274229, #330882, #581899), actuellement ouverts et classés comme "liste de souhaits". J'ai tendance à convenir que ce sont des bogues et que les utilisateurs du système devraient avoir /bin/false comme leur coquille sauf s'il s'avère nécessaire de faire autrement.


Vous n'avez pas à vous en soucier en tant qu'utilisateurs. Ce sont des "utilisateurs" au sens de groupes de sécurité, et non des utilisateurs au sens de personnes "se connectant et utilisant". Si vous regardez dans "/etc/shadow", vous verrez que tous ces "utilisateurs" n'ont pas de mot de passe (soit "x" soit "!" au lieu d'un long hash salé). Cela signifie que ces utilisateurs ne peuvent pas se connecter quoi qu'il arrive.

Cela dit, je ne sais pas si c'est une bonne idée de changer "/bin/sh" en "/bin/false" pour tous ces utilisateurs. Étant donné que les programmes s'exécutent sous ces groupes, cela peut ne pas leur permettre d'exécuter les commandes dont ils ont besoin. Je les laisserais comme "/bin/sh".

Vous n'avez pas à vous soucier de ces utilisateurs. Ne vous souciez que des utilisateurs que vous créez (et de ceux avec des hachages dans "/etc/shadow")


Linux
  1. Pourquoi Bashrc vérifie-t-il si le shell actuel est interactif ?

  2. Pourquoi un shell de connexion « sudo -i » casse-t-il un argument de chaîne de commande Here-doc ?

  3. Le changement de l'échange nécessite-t-il un redémarrage ?

  4. CentOS / RHEL :Comment changer le shell de connexion de l'utilisateur

  5. Pourquoi avez-vous besoin de mettre #!/bin/bash au début d'un fichier de script ?

Les effets de l'ajout d'utilisateurs à un système Linux

Quelle est la différence entre la connexion et le shell sans connexion

Pourquoi le $shlvl commence-t-il au niveau 2 dans les shells sans connexion mais au niveau 1 dans les shells de connexion dans Rhel 7 ?

Pourquoi /bin/sh pointe-t-il vers /bin/dash et non /bin/bash ? ?

Comment puis-je obtenir le nom d'utilisateur dans un Makefile ?

Pourquoi un périphérique RAID 10 doit-il être initialisé ?