Nota: Esto comenzó como un tutorial de "Cómo depurar", pero terminó siendo la solución que me ayudó en un servidor Ubuntu 16.04 LTS.
TLDR : Ejecute landscape-sysinfoy compruebe si ese comando tarda mucho en finalizar; es la impresión de información del sistema en un nuevo inicio de sesión SSH. Tenga en cuenta que este comando no está disponible en todos los sistemas, el landscape-commonpaquete lo instala. ("Pero espera hay mas...")
Inicie un segundo servidor ssh en otro puerto de la máquina que tenga el problema, hágalo en modo de depuración, lo que no hará que se bifurque e imprima mensajes de depuración:
sudo /usr/sbin/sshd -ddd -p 44321
conectarse a ese servidor desde otra máquina en modo detallado:
ssh -vvv -p 44321 username@server
Mi cliente muestra las siguientes líneas justo antes de comenzar a dormir:
debug1: Entering interactive session.
debug1: pledge: network
Buscar en Google eso no es realmente útil, pero los registros del servidor son mejores:
debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051
Noté que cuando cambio UsePAM yesa UsePAM noeste problema se resuelve.
No relacionado con UseDNSninguna otra configuración, solo UsePAMafecta este problema en mi sistema.
No tengo idea de por qué, y tampoco me voy UsePAMa noir porque no sé cuáles son los efectos secundarios, pero esto me permite seguir investigando.
Por lo tanto, no considere que esto sea una respuesta, sino un primer paso para comenzar a descubrir qué está mal.
Entonces continué investigando y corrí sshdcon strace( sudo strace /usr/sbin/sshd -ddd -p 44321). Esto produjo lo siguiente:
sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5) = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022) = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385
La línea /etc/update-motd.dme hizo sospechar, aparentemente el proceso espera el resultado de las cosas que están en/etc/update-motd.d
Así que cd'd en /etc/update-motd.dy pasó un sudo chmod -x *fin de inhibir PAM para ejecutar todos los archivos que generan esta dinámica Message Of The Day, que incluye la carga del sistema y si los paquetes deben ser actualizados, y esto resuelve el problema.
Este es un servidor basado en una CPU N3150 "energéticamente eficiente" que tiene mucho trabajo que hacer las 24 horas del día, los 7 días de la semana, por lo que creo que recopilar todos estos datos motd fue demasiado.
Puedo comenzar a habilitar scripts en esa carpeta de forma selectiva, para ver cuáles son menos dañinos, pero especialmente las llamadas landscape-sysinfoson muy lentas y 50-landscape-sysinfollaman a ese comando. Creo que es el que causa el mayor retraso.
Después de volver a habilitar la mayor parte de los archivos que llegué a la conclusión de que
50-landscape-sysinfoy 99-esmfueron la causa de mis problemas. 50-landscape-sysinfotardó unos 5 segundos en ejecutarse y 99-esmunos 3 segundos. Todos los archivos restantes alrededor de 2 segundos en total.
Ninguno de los dos 50-landscape-sysinfoy 99-esmson cruciales. 50-landscape-sysinfoimprime estadísticas interesantes del sistema (¡y también si tiene poco espacio!) e 99-esmimprime mensajes relacionados conUbuntu Extended Security Maintenance
Finalmente, puede crear un script echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.shy obtener esa impresión a pedido.