web-dev-qa-db-fra.com

Sudo ne reconnaît plus mon mot de passe

  • Le problème se produit sur un serveur distant, donc tout se fait via ssh.
  • Je peux me connecter avec ma clé, pas de problème ici.
  • Je peux changer mon mot de passe à volonté avec passwd (ce qui, je crois, montre que c'est le bon mot de passe pour mon utilisateur).
  • Mon utilisateur est dans le fichier sudoers (j'ai pu vérifier avec pkexec cat /etc/sudoers et saisie du mot de passe root)

Cependant, étant connecté en tant qu'utilisateur normal, je ne peux plus exécuter les commandes Sudo, il dit simplement Sorry, try again comme si le mot de passe avait été mal saisi.

Je n'ai aucune idée de ce qui cause cela, j'ai essayé de changer mon mot de passe, ce que je pouvais, mais cela ne résout pas le problème Sudo.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.10
Release:        12.10
Codename:       quantal
command-lineserverpasswordsudopam
1
Jérémie Parker

Ok, corrigé, mais je ne sais pas vraiment ce qui l'a causé en premier lieu.

Le problème provenait d'une ligne dans /etc/pam.d/common-session-noninteractive

Cela a

session [success=1 default=ignore] pam_succeed_if.so service in cron 
quiet use_uid

Et il semble qu'avoir ceci sur deux lignes au lieu d'une cassait complètement PAM. Je viens de le changer en

session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid

Et maintenant tout est revenu à la normale.

Je dois remercier @AaronD pour son commentaire car il m'a indiqué d'enquêter sur PAM, que je n'ai trouvé rien de mal au début (en regardant /etc/pam.d/Sudo) mais quand j'ai regardé /var/log/auth.log et j'ai remarqué toutes les erreurs PAM que j'avais l'impression de creuser dans la bonne direction.

L'entrée de journal ressemblait à ceci:

Dec 28 15:43:33 srv12120 Sudo: PAM (Sudo) illegal module type: quiet
Dec 28 15:43:33 srv12120 Sudo: PAM pam_parse: expecting return value; [...use_uid]
Dec 28 15:43:33 srv12120 Sudo: PAM (Sudo) no module name supplied

Un peu de recherche sur Google m'a donné ce message sur le forum qui m'a donné la solution mise en évidence ci-dessus.

2
Jérémie Parker

J'ai récemment rencontré ce problème exact, j'ai dû le résoudre légèrement différemment. La cause était très similaire.

Fondamentalement, dans mon cas, en quelque sorte, /etc/pam.d/common-session-noninteractive Avait été légèrement corrompu d'une manière plutôt bizarre. Mon common-session-noninteractive Ressemblait à ceci:

# since the modules above will each just jump around
session required                        pam_permit.so
# The pam_umask module will set the umask according to the system default in
# /etc/login.defs and user settings, solving the problem of different
# umask settings with different shells, display managers, remote sessions etc.
# See "man pam_umask".
session optional                        pam_umask.so
# and here are more per-package modules (the "Additional" block)
Dec 25 11:45:01 websrv CRON[44085]: pam_unix(cron:session): session opened for user root by (uid=0) session 
required                        pam_unix.so
# end of pam-auth-update config

Le problème est le texte Dec 25 11:45:01 websrv CRON[44085]: pam_unix(cron:session): session opened for user root by (uid=0), qui a apparemment été inséré dans le fichier de configuration pam.

Mon hypothèse ici, et je suis vraiment, vraiment deviner, est qu'un script modifiait ce fichier à partir d'un tty attaché au journal d'authentification du noyau d'une manière ou d'une autre, et accidentellement cated ou echoed le texte dans le fichier. Je n'ai jamais rien touché de pam.

Quoi qu'il en soit, il était simple de résoudre le problème une fois que j'ai trouvé le problème, mais la sortie de débogage n'était certainement pas claire.

0
Fake Name