Cada vez que uso sudo se cuelga antes de completar

12

Ya sea que se me solicite una contraseña o no, depende de aceptar la autenticación y ejecutar lo que solicité. En otras palabras sudo ls, colgará durante unos 60 segundos.

Estoy confundido sobre lo que podría estar causando esto. Esto está en Centos 5, y lo miré selinuxy lo configuré como deshabilitado y habilitado, pero no parece tener ningún efecto.

linux centos sudo dlamblin
fuente

Respuestas:

15

De la respuesta de @ TheAndruu a esta pregunta:

Esto sucede si cambia el nombre de host durante el proceso de instalación. Para resolver el problema, edite el archivo / 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]

Tuve exactamente el mismo problema en Fedora 11 y esto lo resolvió.

gareth_bowles
fuente
Solo me aseguré de que mi $HOSTNAMEestuviera en la 127.0.0.1línea. Funcionó. Gracias.
dlamblin
1
Por cierto, ¿ sudo lsutiliza la red de qué manera?
dlamblin
Esto también funcionó para ubuntu 16.04 - excepto que tuve que cambiar el nombre de 127.0.1.1 - 127.0.0.1 era localhost
Bill Ryder
1

A veces, cuando su ruta predeterminada no está configurada, los comandos como sudo se bloquean.

Intente netstat -rverificar si la ruta está configurada correctamente.

¿Esta máquina obtiene sus contraseñas del archivo local / etc / passwd o algo así como ldap?

egorgry
fuente
No está usando ldap; Creo que está usando/etc/passwd
dlamblin
/etc/passwdno se usa para la autenticación, se usa para la identificación para la resolución de nombres. /etc/shadowSe utiliza para la autenticación.
LiraNuna
1

Lo único que puede desear verificar es su archivo /etc/resolv.conf para asegurarse de que tiene una entrada de DNS adecuada allí. He visto en el pasado donde esto puede causar retraso.

Mike Sands
fuente
1

Deberías marcar tres cosas. 1. / etc / hostname 2. / etc / hosts 3. /etc/resolv.conf

Descubrí que mi nombre de host era correcto, que el archivo de hosts era incorrecto y además resolv.conf necesitaba actualizarse.

Paul J. Barrett
fuente
1

Para mí fue instalar krb5-user / config. Noté esto al examinar /var/log/auth.log y ver los intentos de pam_krb5 antes que pam_unix. El uso de apt-get remove para desinstalar esos paquetes lo arregló. No elimine esos paquetes si está en una computadora que requiere kerberos (pam_krb5) obviamente. Mi caída de sudo pasó de 30s a 0s consistentes.

Halsafar
fuente
1

Esto se insinúa en la respuesta de Halsafar , tengo Kerberos habilitado en mi VPN de trabajo pero es inútil cuando estoy apagado, así que cambié el orden del módulo de autenticación para usarlo antes :/etc/pam.d/common-authpam_unixpam_krb5

Antes de:

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

Después:

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

Esto cambió mi sudo de 30 a 0 como lo hizo en la respuesta de Halsafar.

dcmorse
fuente
0

En Solaris 10 sudo estuvo colgado durante unos 30 segundos. Con la ayuda de Truss, finalmente pude determinar que estaba colgando en el comando de cuota que estaba colgando en un montaje NFS. Desmontar el recurso compartido NFS eliminó el bloqueo. Todavía no he determinado qué está mal con el recurso compartido.

otislafayette
fuente
0

En Fedora 30, Snapd hace que sudo, su, etc., se vuelvan muy lentos, y también otros problemas relacionados con la sesión.

Desinstalar snapd, si estás en Fedora, es una alternativa recomendada.

notcarlsatan
fuente