Je dois reconnaître que la réponse la plus acceptée ici est proche, mais pas tout à fait exacte.

Je viens de résoudre ce problème moi-même, et la solution pour moi a été de modifier l'entrée gdm.schema suivante :

(original)
<schema>
      <key>greeter/IncludeAll</key>
      <signature>b</signature>
      <default>true</default>
    </schema>

(after my edit)
<schema>
      <key>greeter/IncludeAll</key>
      <signature>b</signature>
      <default>false</default>
    </schema>

L'effet de ceci est que toute la liste des utilisateurs est désactivée, ce qui, si j'interprète correctement la question originale, est en fait ce que le PO (gruszczy) avait l'intention de faire. Cela élimine le besoin d'élaborer une longue ligne d'exclusions, car tous les ID utilisateur, quel que soit leur numéro, sont exclus dès que ce paramètre est modifié. J'ai personnellement appliqué ce paramètre à 3 serveurs CentOS 6.2 distincts au travail, auxquels on accède occasionnellement via XDMCP (en utilisant xrdp > vnc-server > xinetd > gdm > gnome) sur RDP, ce qui permet à certains de nos administrateurs Linux moins expérimentés de travailler sur ces systèmes avec une formation minimale.

Tout ceci étant dit, même si je suis d'accord pour dire qu'un administrateur système inexpérimenté devrait apprendre dès le début à travailler à partir d'un compte personnel (peut-être avec un accès sudo) plutôt qu'en tant que root, si vous avez l'expérience pour travailler correctement avec ce compte, il n'y a aucun mal à le faire. Assurez-vous simplement de savoir ce que vous faites avant de le faire. Dans le cas de mes autres administrateurs système, j'ai ajouté CentrifyDC pour la prise en charge d'Active Directory à tous ces systèmes et j'ai configuré les systèmes de sorte que les AD-UserID puissent être utilisés pour les sessions de bureau tout en conservant les droits du groupe de sécurité AD de l'utilisateur. Personnellement, étant donné que j'ai conçu tous ces serveurs et que j'utilise Linux depuis plus de 15 ans, je ne pense pas à utiliser la racine pour accélérer les choses. En fait, j'ai tendance à activer le compte root sur les systèmes où il a été désactivé, juste pour pouvoir utiliser ce compte et aller droit au but pour faire avancer les choses. L'essentiel, en fait, est de prendre l'habitude de créer une copie de sauvegarde de tout fichier avant de le modifier. Cela vous protégera contre la plupart des mésaventures et vous permettra de récupérer le système si vous effectuez une modification qui rendrait le système inaccessible (il suffit de démarrer sur un CD live et de réparer ce qui doit l'être).

IMHO, je pense que le mantra "ne jamais se connecter en tant que root" n'est là que pour protéger les sysadmins débutants d'eux-mêmes. Mais si vous atteignez un niveau de compétence avec Linux tel que vous pouvez concevoir un système à partir de n'importe quel système d'exploitation Linux en très peu de temps et qu'il fonctionne à chaque fois, alors il n'y a aucune raison de respecter le mantra "ne jamais se connecter en tant que root" car à ce moment-là, vous êtes prêt à assumer la responsabilité qui accompagne l'utilisation de ce compte. Cela est particulièrement vrai dans les environnements qui utilisent CentrifyDC pour la prise en charge d'AD, car "root" devient le compte local de l'administrateur système et est (généralement) activé automatiquement. Je pense donc qu'il est préférable d'aller droit au but et de faire de la définition du mot de passe du compte root l'une des toutes premières tâches que j'effectue lors de tout déploiement aujourd'hui. Bien sûr, je pourrais faire le truc du "login sous mon propre ID, puis sudo up", mais personnellement je ne ressens pas le besoin de faire les choses de cette façon. Votre avis peut varier...

Changer le login utilisateur Shell en une chaîne vide dans /etc/passwd

Par exemple, changer :

# Change
example:x:2001:2001:Example User,,,:/home/example:/bin/bash

# To
example:x:2001:2001:Example User,,,:/home/example:

J'ai redémarré mon gestionnaire d'affichage et j'ai constaté que cela prenait effet.

sudo service lightdm restart
# (or gdm, mdm, ...)

Il m'a fallu des semaines pour identifier que c'était la raison pour laquelle les utilisateurs étaient cachés dans l'écran d'accueil du gestionnaire d'affichage. Il est évident que le répertoire /var/lib/AccountService/users est ignoré par MDM, et sans doute aussi par GDM. Je n'ai pas été jusqu'à ajouter une balise Exclude=user1,user2 ou un Include=user3 sous [greeter] dans /etc/mdm/mdm.conf, ou créer un /etc/mdm/custom.conf, comme une autre boîte cachait les utilisateurs ajoutés via useradd très bien, tandis que les utilisateurs ajoutés avec adduser ont été montrés. Définir le login Shell à /bin/false refuse toute connexion à cet utilisateur, que je souhaite toujours suer en tant que. Mais cela cache également l'utilisateur dans l'écran de connexion si vous voulez que cet utilisateur soit carrément inaccessible.

Cela a fonctionné pour moi sur Zorin 16 - gdm3

Décommentez la ligne qui dit disable-user-list=true dans /etc/gdm3/greeter.dconf-defaults

nano /etc/gdm3/greeter.dconf-defaults

# - Disable user list
disable-user-list=true

Puis

/etc/gdm3/greeter.dconf-defaults