Chaque fois que j'utilise sudo, il se bloque avant de terminer

12

Que l'on me demande ou non un mot de passe, cela dépend de l'acceptation de l'authentification et de l'exécution de ce que j'ai demandé. En d'autres termes, il sudo lsse bloque pendant environ 60 secondes.

Je suis confus quant à ce qui pourrait être à l'origine de cela. C'est sur Centos 5, et j'ai regardé selinuxet réglé à la fois sur désactivé et activé, mais cela ne semble pas avoir d'effet.

linux centos sudo

— dlamblin
source

15

De la réponse de @ TheAndruu à cette question:

Cela se produit si vous modifiez le nom d'hôte pendant le processus d'installation. Pour résoudre le problème, modifiez le fichier / etc / hosts

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 [ADD_YOURS_HERE] 
:: 1 localhost localhost.localdomain localhost6 localhost6.localdomain6 [ADD_YOURS_HERE]

J'ai eu exactement le même problème sur Fedora 11 et cela l'a résolu.

— gareth_bowles
source

Je viens de m'assurer que mon $HOSTNAMEétait bien dans la 127.0.0.1ligne. Ça a marché. Merci.

— dlamblin

1

BTW sudo lsutilise le réseau de quelle manière?

— dlamblin

Cela a également fonctionné pour Ubuntu 16.04 - sauf que j'ai dû changer le nom pour 127.0.1.1 - 127.0.0.1 était localhost

— Bill Ryder

1

Parfois, lorsque votre itinéraire par défaut n'est pas défini, des commandes comme sudo se bloquent.

Essayez netstat -rde vérifier si l'itinéraire est correctement défini.

Cette machine obtient-elle ses mots de passe à partir du fichier local / etc / passwd ou quelque chose comme ldap?

— egorgry
source

Il n'utilise pas ldap; Je pense qu'il utilise/etc/passwd

— dlamblin

/etc/passwdn'est pas utilisé pour l'authentification, il est utilisé pour la résolution id to name. /etc/shadowest utilisé pour l'authentification.

— LiraNuna,

1

La seule autre chose que vous voudrez peut-être vérifier est votre fichier /etc/resolv.conf pour vous assurer que vous y avez une entrée DNS appropriée. J'ai vu dans le passé où cela peut entraîner des retards.

— Mike Sands
source

1

Vous devriez vérifier trois choses. 1. / etc / hostname 2. / etc / hosts 3. /etc/resolv.conf

J'ai trouvé que mon nom d'hôte était correct, que le fichier hosts était incorrect et que le resolv.conf avait besoin d'être mis à jour.

— Paul J. Barrett
source

1

Pour moi, c'était krb5-user / config en cours d'installation. J'ai remarqué cela en examinant /var/log/auth.log et en voyant les tentatives de pam_krb5 avant pam_unix. L'utilisation d'apt-get remove pour désinstaller ces packages l'a corrigé. Ne supprimez pas ces packages si vous êtes sur un ordinateur nécessitant des kerberos (pam_krb5) évidemment. Mon blocage sudo est passé de 30 à 0.

— Halsafar
source

1

Ceci est indiqué dans la réponse de Halsafar , j'ai Kerberos activé sur mon VPN de travail mais il est inutile quand je suis hors de lui, j'ai donc changé l'ordre du module d'authentification à utiliser avant :/etc/pam.d/common-authpam_unixpam_krb5

Avant:

auth [success=4 default=ignore] pam_krb5.so ...
auth [success=3 default=ignore] pam_unix.so ...

Après:

auth [success=4 default=ignore] pam_unix.so ...
auth [success=3 default=ignore] pam_krb5.so ...

Cela a changé mon sudo de 30s à 0s comme il l'a fait dans la réponse de Halsafar.

— dcmorse
source

0

Sous Solaris 10, sudo était suspendu pendant environ 30 secondes. Avec l'aide de Truss, j'ai finalement pu déterminer qu'il était suspendu à la commande quota qui était suspendue à une monture NFS. Le démontage du partage NFS a éliminé le blocage. Je n'ai pas encore déterminé ce qui ne va pas avec la part.

— otislafayette
source

0

Dans Fedora 30, Snapd ralentit très rapidement sudo, su, etc., ainsi que d'autres problèmes liés à la session.

La désinstallation de snapd, si vous êtes chez Fedora, est une alternative recommandée.

— notcarlsatan
source