Sur ma machine perso GNU/Linux Buster, j'ajoute un utilisateur :

$ sudo adduser toto
[sudo] Mot de passe de guigui : 
Ajout de l'utilisateur « toto » ...
Ajout du nouveau groupe « toto » (1002) ...
Ajout du nouvel utilisateur « toto » (1002) avec le groupe « toto » ...
Création du répertoire personnel « /home/toto »...
Copie des fichiers depuis « /etc/skel »...
Current password: 
New password: 
New password (again): 
Mot de passe inchangé
passwd: Erreur de manipulation du jeton d'authentification
passwd: password unchanged

Le comportement est identique après un su - root.

Depuis quand passwd demande l'ancien mot de passe quand on crée un compte ?! Depuis quand cette demande se fait-elle en anglais ?

Je crée un compte sans mot de passe (entrée, entrée, entrée, entrée, etc.) puis je tente de changer le mdp :

# passwd toto 
Current password: 
New password: 
New password (again): 
Aucun mot de passe fourni
passwd: Erreur de manipulation du jeton d'authentification
passwd: password unchanged

… … …

J'ai trouvé l'origine du problème avec de la chance : j'ai installé le module pam_script. Celui-ci modifie le fichier /etc/pam.d/common-password de la manière suivante :

- password        [success=1 default=ignore]      pam_unix.so obscure sha512
+ password        sufficient                      pam_script.so
+ password        [success=1 default=ignore]      pam_unix.so obscure use_authtok try_first_pass sha512

C'est donc pam_script qui affiche « Current password » / « New password » / « New password (again) ». A priori, ce n'est pas un script lancé par pam_script mais bien pam_script lui-même qui affiche cela, car, en mettant mon /etc dans un dépôt git, je n'ai pas trouvé un quelconque script et l'installation de libpam-script ne modifie / n'ajoute pas d'autres fichiers dans /etc.

Du coup, si l'on répond uniquement avec entrée, on devrait passer au module suivant, pam_unix.so, non ? Oui.

Donc retrouver le comportement habituel ? Non. Car pam_unix est exécuté avec l'argument « use_authtok » qui lui ordonne de définir le nouveau mot de passe à la valeur fournie par un module précédent… Or, nous ne l'avons pas saisi. Le module pam_unix affiche donc « Aucun mot de passe fourni ». Puis le module pam_deny afffiche les deux dernières lignes.

Saisir un nouveau mot de passe sans saisir le mot de passe actuel change rien : la comparaison entre le mot de passe enregistré en base et celui saisi échouera, donc pam_unix échouera.

Solution ? Soit désinstaller libpam-script (je l'avais installé pour tester des choses). Soit commenter la ligne pam_script et virer les arguments « use_authtok try_first_pass » de pam_unix.