Lo primero sudoque ingreso en mi servidor Ubuntu 14.04 siempre es lento. La solicitud de contraseña se muestra de inmediato, pero después de presionar Enter, toma unos 10-15 segundos hasta que se imprime la salida. Todos los comandos sudo después de esto se ejecutan instantáneamente.
Ejecutar algo así sudo strace -S time -c sudo echo hino muestra nada útil en este caso, ya que el sudo de sudo echo hiya es el segundo sudo y se ejecuta rápidamente. Si pasa algún tiempo y tengo que volver a ingresar la contraseña en una sesión en ejecución, vuelve a ser lenta.
Todas las soluciones que encontré fueron sobre agregar su nombre de host como resolución para 127.0.0.1 en el /etc/hostsarchivo, lo cual hice en vano. su rootSe ejecuta al instante. Lo único que recuerdo haber cambiado en los últimos días es la máscara de red de una subred que el servidor está enrutando, instalando samba, dnsutils y bind9. Pero ninguno de esos procesos se está ejecutando y el problema persiste, en el acceso físico, en las sesiones ssh y en las sesiones tmux.
EDITAR: nuevo enfoque
Intenté correr sudo tcpdump -vvvi any > tcpdump.log mientras tenía todas las NIC desconectadas. El registro muestra mucho de lo siguiente:
18:35:09.453399 IP (tos 0x0, ttl 64, id 49112, offset 0, flags [DF], proto UDP (17), length 76)
localhost.38498 > localhost.domain: [bad udp cksum 0xfe4b -> 0x1050!] 58546+ SRV? _kerberos._udp.KF.OURLOCALDOMAIN.DE. (48)
18:35:09.457412 IP (tos 0x0, ttl 64, id 49113, offset 0, flags [none], proto UDP (17), length 76)
localhost.domain > localhost.38498: [bad udp cksum 0xfe4b -> 0x8fcd!] 58546 ServFail q: SRV? _kerberos._udp.KF.OURLOCALDOMAIN.DE. 0/0/0 (48)
Las mismas entradas se muestran con tcp instad de udp. Reemplacé el nombre de dominio de nuestra universidad con OURLOCALDOMAIN.
Ahora creo que kerberos podría tener algo que ver con eso, pero eliminé el /etc/krb5.conf y lo reinicié, aún sin cambios. Me parece que el servidor intenta validarse en un servidor central Kerberos de nuestra red universitaria. Sé que algunos años antes, esta IP se registró en un servidor que ejecutaba samba para nuestro departamento. ¿Podría haber una conexión? Cambié mi nombre de host al que se usaba en ese momento, sin cambios en el comportamiento de sudo. Lmwangi sugiere algo sobre PAM, del cual tengo poco conocimiento, así que no sé cómo abordar esto. También recordé que cambié de Heimdal Kerberos a MIT Kerberos cuando instalé samba, porque tuve problemas durante la instalación de samba. También voy a probar las ideas de los comentarios en los próximos días, pero viajaré por un par de días, por lo que podría llevar algo de tiempo.
EDIT 2: resuelto
Había una entrada de dns-search heredada en el /etc/network/interfacesque desordenó todo. Me siento muy estupido Todo funciona ahora.
sudo -kpara eliminar su credencial almacenada en caché. Encontré que strace -Tro sudo.log sudo echo hifue útil ya que la última columna muestra el tiempo en cada llamada. greppara unamey socketcomo entrante.
-ropción (que tal vez debería eliminarse). Comience buscando las llamadas largas desde la -Topción: son las que se encuentran dentro de <y >- 0.000097 segundos en su caso.
straceeventualmente lo llevará allí, pero este es probablemente un problema de configuración de nivel superior. La mayoría de las pausas largas durante la autenticación se deben a la imposibilidad de acceder a servidores remotos y a tener que esperar un tiempo de espera. Es posible que el cambio de subred coloque al servidor de autenticación en una subred diferente a esta. sudoguarda temporalmente un registro de autenticación exitosa debajo, /varpor lo que esta es probablemente la razón por la cual las invocaciones posteriores se ejecutan instantáneamente.
stracete permitirá ejecutarlo sin el primerosudo. También podría ser útil usar la-o <file>opción para guardar la salida en un archivo para su análisis.