Re: /etc/securetty
Le 14-11-2020, à 20:51:42 +0100, l0f...@tuta.io a écrit : 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 plein dans le mille ! Je suis sous Testing 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. Ok, je ne savais pas. J'ai l'impression que ta remontée est du même acabit que le bug #931899 [3]. En effet, c'est très probablement la même chose chez moi, 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. Ce qui semble logique en effet. 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 Oui j'ai bien ça. 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... Bon, je me lance, on verra bien si le monde arrête de tourner après ça. 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. Tous mes utilisateurs ont un mot de passe. Merci à toi et très bon dimanche ! Steve
Re: /etc/securetty
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
Re: /etc/securetty
Le 13-11-2020, à 19:18:00 +0100, l0f...@tuta.io a écrit : Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip à faire ? D'après cette phrase je comprends que ton /etc/securetty existe (mais que les droits sont probablement KO à cause du "No such file or directory" plus haut) Au début, il n'existait pas. J'ai tenté d'en créer un vide avec 'touch /etc/securetty' en espérant que ça passerait. Ensuite, je me suis aperçu que ça ne changeait rien, donc je l'ai viré. 13 nov. 2020 à 07:55 de dl...@bluewin.ch: Non il n'existe pas. Quel paquet aurait dû le créer et quel devrait être son contenu ? Maintenant je comprends que ton /etc/securetty n'existe pas finalement. Bref tu m'as un peu perdu... ;) Désolé :) 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 'dpkg --listfiles login' ne me liste pas ce fichier Idem ici. Du coup que donne un simple : dpkg -l login C'est installé. J'y perds mon grec… Merci pour l'intérêt. Steve
Re: /etc/securetty
On 13/11/2020 07:55, steve wrote: Le 12-11-2020, à 17:18:29 +0100, Belaïd a écrit : Bonjour, Le fichier est toujours utilisé de nos jours , c'est juste que les applications n'y accède pas directement mais a travers Pam. Donc ton fichier existe bien sur ta config ? Et que contient-il actuellement ? Non il n'existe pas. Quel paquet aurait dû le créer et quel devrait être son contenu ? Tu peux avoir l'info par la commande suivante: apt-file search /etc/securetty -- Fabien
Re: /etc/securetty
Bonjour, 12 nov. 2020 à 17:08 de dl...@bluewin.ch: > cupsd: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or > directory > > [...] > > Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip à > faire ? > D'après cette phrase je comprends que ton /etc/securetty existe (mais que les droits sont probablement KO à cause du "No such file or directory" plus haut) 13 nov. 2020 à 07:55 de dl...@bluewin.ch: > Non il n'existe pas. > > Quel paquet aurait dû le créer et quel devrait être son contenu ? > Maintenant je comprends que ton /etc/securetty n'existe pas finalement. Bref tu m'as un peu perdu... ;) 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". > Idem ici. Du coup que donne un simple : dpkg -l login Bien cordialement, l0f4r0
Re: /etc/securetty
Le 2020-11-13 07:55, steve a écrit : Le 12-11-2020, à 17:18:29 +0100, Belaïd a écrit : Le fichier est toujours utilisé de nos jours , c'est juste que les applications n'y accède pas directement mais a travers Pam. Donc ton fichier existe bien sur ta config ? Et que contient-il actuellement ? Non il n'existe pas. Quel paquet aurait dû le créer et quel devrait être son contenu ? Le fichier existe sur mon système (Buster assez fraîchement installé). Il appartient au paquet "login". Sébastien
Re: /etc/securetty
- Mail original - > De: "steve" > À: debian-user-french@lists.debian.org > Envoyé: Vendredi 13 Novembre 2020 08:56:51 > Objet: Re: /etc/securetty > > Le 13-11-2020, à 08:29:07 +0100, Bernard Schoenacker a écrit : > > > Merci pour le lien. > > > J'ai aussi ça d'installé mais pas de fichier /etc/securetty. En as-tu > un > chez toi ? > bonjour, désolé,mais je n'ai plus ce fichier sur mon ordi portable et c'est pam qui fait le travail en revanche, si j'avais plusieurs utilisateurs à gérer, je pressent que c'est ldap qui fera le job : - libpam-ldap - libpam-ldapd - sudo-ldap - libpam-ccreds merci pour ton aimable attention bien à toi bernard
Re: /etc/securetty
Le 13-11-2020, à 08:29:07 +0100, Bernard Schoenacker a écrit : voici une réponse qui devrait te satisfaire : https://unix.stackexchange.com/questions/41840/effect-of-entries-in-etc-securetty#41939 Merci pour le lien. et pour debian : apt-file search pam_securetty libpam-doc: /usr/share/doc/libpam-doc/html/sag-pam_securetty.html libpam-modules: /lib/x86_64-linux-gnu/security/pam_securetty.so libpam-modules: /usr/share/man/man8/pam_securetty.8.gz J'ai aussi ça d'installé mais pas de fichier /etc/securetty. En as-tu un chez toi ?
Re: /etc/securetty
- Mail original - > De: "steve" > À: debian-user-french@lists.debian.org > Envoyé: Vendredi 13 Novembre 2020 07:55:50 > Objet: Re: /etc/securetty > > Le 12-11-2020, à 17:18:29 +0100, Belaïd a écrit : > > > Non il n'existe pas. > > Quel paquet aurait dû le créer et quel devrait être son contenu ? > bonjour steve, voici une réponse qui devrait te satisfaire : https://unix.stackexchange.com/questions/41840/effect-of-entries-in-etc-securetty#41939 et pour debian : apt-file search pam_securetty libpam-doc: /usr/share/doc/libpam-doc/html/sag-pam_securetty.html libpam-modules: /lib/x86_64-linux-gnu/security/pam_securetty.so libpam-modules: /usr/share/man/man8/pam_securetty.8.gz merci pour ton aimable attention bien à toi bernard
Re: /etc/securetty
Le 12-11-2020, à 17:18:29 +0100, Belaïd a écrit : Bonjour, Le fichier est toujours utilisé de nos jours , c'est juste que les applications n'y accède pas directement mais a travers Pam. Donc ton fichier existe bien sur ta config ? Et que contient-il actuellement ? Non il n'existe pas. Quel paquet aurait dû le créer et quel devrait être son contenu ?
Re: /etc/securetty
Bonjour, Le fichier est toujours utilisé de nos jours , c'est juste que les applications n'y accède pas directement mais a travers Pam. Donc ton fichier existe bien sur ta config ? Et que contient-il actuellement ? Le jeu. 12 nov. 2020 17:09, steve a écrit : > Bonjour, > > Depuis quelques jours j'ai le message suivant qui pollue les logs: > > cupsd: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or > directory > > Après quelques recherches, il semble que ce fichier est un reliquat d'un > passé pas trop lointain qui devait spécifier à root sur quel tty il > pouvait se connecter. Or je ne vois pas pourquoi cups en parle et > surtout, je n'arrive plus à imprimer depuis quelques jours. Pas sûr que > ce soit lié mais sait-on jamais. > > Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip à > faire ? > > Merci > > Steve > >
