Primer sudo siempre lento

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.

Sospecho que su casilla está intentando contactar un servicio de autenticación externo (piense en NIS / LDAP) usando PAM ...

Si entiendo bien PAM, no podrás ver la búsqueda de PAM en tus llamadas de strace. Le sugiero que ejecute tshark / tcpdump y vea si puede correlacionar el tráfico de red específico con sus intentos de sudo. Los sospechosos aquí serían búsquedas de DNS y | Llamadas LDAP.

tcpdump -i eth0 -w network.pcap -s0 -Av

Si descubre qué está causando las búsquedas, busque el módulo PAM relevante para editar y solucionar el problema. Alternativamente, si se trata de una búsqueda de DNS, simplemente agregue una entrada / etc / hosts para falsificar el nombre y redirigir a localhost. Esto hará que su sudo sea rápido ya que la búsqueda será rápida y redirigirá al localhost y la transacción de red fallará rápidamente ya que no hay nada escuchando en localhost ...