Bonsoir, 14 nov. 2020 à 17:24 de dl...@bluewin.ch:
>> 13 nov. 2020 à 17:18 de s-liste-debian-user-fre...@pipoprods.org: >> >>> Le fichier existe sur mon système (Buster assez fraîchement installé). >>> Il appartient au paquet "login". >>> > Pas chez moi: > > apt-file search /etc/securetty > rear: /usr/share/rear/skel/Linux-ia64/etc/securetty > Ok, je parie que tu ne fais pas tourner Buster mais plutôt Testing ou Unstable. Vrai ? En effet login ne fournit plus /etc/securetty après Buster [1][2] d'où ta sortie de commande différente de la mienne+Sébastien. J'ai l'impression que ta remontée est du même acabit que le bug #931899 [3]. Auquel cas, vu que le fichier n'est plus fourni, pam devrait arrêter de proposer des options qui y font appel au-delà de Buster. Il semble que la ligne fautive soit dans /etc/pam.d/common-auth, plus précisément l'argument "nullok_secure" envoyé au module pam_unix.so. Je te laisse regarder si t'as bien cette ligne. Sous Buster chez moi c'est la suivante : auth [success=1 default=ignore] pam_unix.so nullok_secure Visiblement, supprimer "nullok_secure" résout le pb d'accès. Pas certain que ce soit une perte de sécurité dans la mesure où cet argument autorise lui-même une certaine largesse... nullok_secure: The default action of this module is to not permit the user access to a service if their official password is blank. The nullok_secure argument overrides this default and allows any user with a blank password to access the service as long as the value of PAM_TTY is set to one of the values found in /etc/securetty. Bien cordialement, l0f4r0 [1] : https://packages.debian.org/bullseye/amd64/login/filelist [2] : https://packages.debian.org/sid/amd64/login/filelist [3] : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931899